fragnol.net

MAJ article Seedbox

Wed, 04 Nov 2015 11:53:52 GMT

Je me suis aperçu que le fork de sarakha63 n’était plus disponible depuis un temps certains… De ce fait je n’utilise plus Sickbeard, mais Sickrage qui inclut T411 dans les providers torrents. Concernant Couchpotato je l’ai réinstallé via le fork original (celui de RuudBurger). J’ai ensuite rajouté manuellement le provider T411 fournit par Djoole vers le dossier /var/opt/couchpotato/custom_plugins/. Je mettrais à jour les billets lorsque j’aurais un peu de temps…

Créer sa Seedbox sous Ubuntu 14.10 server avec un VPN

Mon, 09 Feb 2015 13:01:09 GMT

Déplorant la connexion montante ridicule que j’ai dans ma campagne, j’ai cherché comment pallier à ce problème depuis plusieurs années… En effet proposer des services à l’internet requiert d’avoir un débit montant conséquent et une disponibilité accrue. Je m’était donc tourné vers un serveur dédié chez online.net et maintenant chez kimsufi.com. Ayant à disposition cette machine, je m’étais demandé si il ne serait pas intelligent de se servir de ce serveur comme “cache” pour mes téléchargements peer to peer légaux… L’avantage est le débit très important de mon serveur ! Je me suis donc renseigné et j’ai appris que ce que je voulais entreprendre avait un nom : UNE SEEDBOX…

Cliquez ici pour zoomer sur l’image

Le schéma ci-dessus explique parfaitement mon “projet” :

Je dispose de deux services, Couchpotato (films) et Sickbeard (séries) qui se chargent de vérifier chez un provider torrent (T411, cpasbien…) la disponibilité des films / séries que j’ai renseigné au préalable. C’est mon unique point d’entrée. Lorsqu’un film est disponible chez mon provider torrent, Couchpotato se charge de télécharger le fichier .torrent et l’envoie vers mon client bittorent, ici Transmission.

Mon service Transmission a un tunnel VPN dédié chez VPNfacile.net. Ainsi les données qui passent par ce tunnel sont cryptées et l’ip exposé à l’extérieur est celle de ma passerelle VPN.

Quand le téléchargement est terminé, Couchpotato est averti et se charge du post-processing à savoir renommer le fichier et le copier vers l’emplacement suivant /mnt/Films (ou /mnt/Series). Cet emplacement est un montage utilisant le file system SSHFS qui permet de monter un tunnel SSH vers mon Nas Synology. De cette manière, quand mon film est téléchargé il est automatiquement rapatrié chez moi, avec une notification par mail pour m’avertir.

Maintenant nous allons voir comment mettre ceci en place :

C’est parti, mon geeky !

Un Firewall avec Iptables

Thu, 05 Feb 2015 13:49:33 GMT

Après avoir sécurisé l’accès SSH de notre serveur il convient maintenant de “l’habiller”. En effet celui ci est actuellement “à poil” sur internet, nous allons donc lui faire revêtir une “armure” en veillant à ce que notre serveur puisse tout de même “respirer” ! Bon ok, l’analogie n’est peut-être pas très bien trouvé mais l’essentiel est là… Nous allons installer un pare-feu sur notre machine Linux à l’aide de l’incontournable Iptables.

Au lieu de repartir de zéro j’ai modifié le script iptables de « Nicolargo » (http://blog.nicolargo.com/ ) et je l’ai adapté à mes besoins. Personnellement je n’utilise aucun contrôle sur le trafic sortant de mon serveur, uniquement sur l’entrant.

Commencez par créer votre script :

nano /etc/init.d/firewall.sh

Copiez coller le script ci-dessous (je vous expliquerais 2-3 choses plus bas :

#!/bin/sh
#
# Simple Firewall configuration.
#
# Author: Nicolargo
# Edit : fmplaw
#
# chkconfig: 2345 9 91
# description: Activates/Deactivates the firewall at boot time
#
### BEGIN INIT INFO
# Provides:          firewall.sh
# Required-Start:    $syslog $network
# Required-Stop:     $syslog $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start firewall daemon at boot time
# Description:       Custom Firewall script.
### END INIT INFO
 
PATH=/bin:/sbin:/usr/bin:/usr/sbin
 
# Services that the system will offer to the network
# SSH = 22
TCP_SERVICES="22"
UDP_SERVICES=""

if ! [ -x /sbin/iptables ]; then
exit 0
fi
 
##########################
# Start the Firewall rules
##########################
 
fw_start () {
 
# Input traffic:
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Services
if [ -n "$TCP_SERVICES" ] ; then
for PORT in $TCP_SERVICES; do
/sbin/iptables -A INPUT -p tcp --dport ${PORT} -j ACCEPT
done
fi
if [ -n "$UDP_SERVICES" ] ; then
for PORT in $UDP_SERVICES; do
/sbin/iptables -A INPUT -p udp --dport ${PORT} -j ACCEPT
done
fi

# Remote testing
/sbin/iptables -A INPUT -p icmp -j ACCEPT
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -P INPUT DROP
/sbin/iptables -A INPUT -j LOG
 
# Other network protections
# (some will only work with some kernel versions)
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 0 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
 
}
 
##########################
# Stop the Firewall rules
##########################
 
fw_stop () {
/sbin/iptables -F
/sbin/iptables -t nat -F
/sbin/iptables -t mangle -F
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT
}
 
##########################
# Clear the Firewall rules
##########################
 
fw_clear () {
/sbin/iptables -F
/sbin/iptables -t nat -F
/sbin/iptables -t mangle -F
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables -P OUTPUT ACCEPT
}
 
##########################
# Test the Firewall rules
##########################
 
fw_save () {
/sbin/iptables-save > /etc/iptables.backup
}
 
fw_restore () {
if [ -e /etc/iptables.backup ]; then
/sbin/iptables-restore < /etc/iptables.backup
fi
}
 
fw_test () {
fw_save
sleep 30 && echo "Restore previous Firewall rules..." && fw_restore &
fw_stop
fw_start
}
 
case "$1" in
start|restart)
echo -n "Starting firewall.."
fw_stop
fw_start
echo "done."
;;
stop)
echo -n "Stopping firewall.."
fw_stop
echo "done."
;;
clear)
echo -n "Clearing firewall rules.."
fw_clear
echo "done."
;;
test)
echo -n "Test Firewall rules..."
fw_test
echo -n "Previous configuration will be restore in 30 seconds"
;;
*)
echo "Usage: $0 {start|stop|restart|clear|test}"
echo "Be aware that stop drop all incoming/outgoing traffic !!!"
exit 1
;;
esac
exit 0

Ensuite rendez le exécutable :

chmod +x /etc/init.d/firewall.sh

Puis on le lance au démarrage :

update-rc.d firewall.sh defaults

Cela dit il peut-être utile de comprendre comme il fonctionne… Tout d’abord il reconnait les paramètres suivants :

start : permet de lancer le script.
stop : ATTENTION réinitialise les règles iptables et empêche le trafic forward et input.
restart : redémarre le script.
clear : réinitialise les règles iptables et autorise tous les trafics.
test : permet de tester la configuration iptables 30 sec.
save : permet de sauvegarder la conf iptables.
restore : permet la restauration de la conf iptables.

L’intérêt de ce script est qu’il est très facilement éditable. En effet si vous voulez ajouter le service ftp à votre serveur il est impératif d’ouvrir les ports 20 et 21 en TCP. Rien de plus simple, éditez votre script :

nano /etc/init.d/firewall.sh

Puis rajoutez ces ports à la ligne 26 (voir script ci-dessus) de la variable TCP_SERVICES:

# Services that the system will offer to the network
# SSH = 22
TCP_SERVICES="22 20 21"
UDP_SERVICES=""

Sauvegardez ces changements et relancez le services :

/etc/init.d/firewall.sh restart

Et voilà ! Simple, non ?

Sécurisation du service SSH

Wed, 04 Feb 2015 16:07:02 GMT

En ces temps de crises on cherche un peu partout où il est possible de faire des économies (c’est la mode !). J’ai remarqué que chez Online.net mon serveur dédié Dedibox® SC gen2 était passé de 9,99€HT à 5,99€HT !!! Or pour en bénéficier il faut résilier son contrat et en prendre un autre, et donc se taper toute une migration… J’en ai profité pour regarder ce qu’il se passait chez la concurrence et j’ai décidé de prendre pour le même prix un serveur plus robuste chez Kimsufi (OVH), un KS-2 ! Je vais donc rédiger une série d’articles pour parler de ma migration en général, et dans l’immédiat de ce bon vieux service SSH…

La premier chose est de créer un nouvel utilisateur qui nous servira a nous connecter en SSH à notre serveur (en effet se connecter en root en ssh est à proscrire) :

adduser florent

Nous allons ensuite créer un groupe dans lequel nous renseignerons tous les utilisateurs ayant le droit de se connecter en ssh :

addgroup sshusers

Puis nous ajoutons notre utilisateur florent à ce groupe :

adduser florent sshusers

Nous allons passer a la configuration du fichier de config du service SSH afin de sécuriser notre serveur. Commençons part changer le port par défaut . Pour cela il faut éditer le fichier /etc/ssh/sshd_config et changer la ligne port avec le numéro de port qui vous convient :

Port 2552 #par exemple

Nous allons ensuite rajouter la directive autorisant le groupe sshusers :

AllowGroups sshuers

Puis nous empechons le compte root de se connecter :

PermitRootLogin no

Il est maintenant possible de se connecter avec l’utilisateur “florent” en utilisant le port 2522 sur notre client ssh (Putty par exemple).

Cependant je préfère m’identifier via non plus un mot de passe mais un certificat . Cette méthode est beaucoup plus sécurisé que la première. La première étape consiste à créer nos clés, pour cela rien de plus simple. Sur votre serveur linux tapez cette commande :

ssh-keygen -t rsa

Personnellement je ne choisis pas de “passphrase”, cela me permet d’avoir une connexion a mon serveur sans interaction. Cela dit, le risque est qu’une personne récupère notre clé privé et l’utilise, c’est à vous de voir !

En fonction de l’utilisateur avec lequel vous êtes connecté vos clés iront soit dans /root/.ssh/ ou ~/.ssh/. Vous devriez avoir deux clés avec vous :

Un fichier id_rsa qui corresponds à la clé privée. Cette clé est confidentiel et sera utilisé par notre client ssh.
Un fichier id_rsa.pub qui corresponds à la clé publique. C’est cette clé qui transite sur internet vers les machines que nous voulons controler.

A ce stade vous allez peut-être tiquer : “Mais pourquoi on crée ces clés sur le serveur Linux alors qu’on veut justement le contrôler ???” et vous aurez raison ! A vrai dire notre serveur Linux sait nativement créer des certificats (ou presque) alors que sur notre machine windows c’est… moins évident !

Sur notre machine cliente :

Bref nous allons maintenant rapatrier notre clé id_rsa sur notre machine cliente (en occurrence un Windows 7 avec Putty). Pour le moyen de rapatriement je vous laisse le choix (sFTP, copier/coller, mail…). Afin d’utiliser cette clé avec Putty nous allons devoir la convertir avec Puttygen.exe.

Ouvez cet EXE puis cliquez dans le menu “Conversions -> Import Key” et choisissez votre clé id_rsa. Ensuite cliquez dans le menu “Conversions -> Export OpenSSH Key” afin de générer votre fichier.ppk que Putty saura exploiter.

Ensuite ouvrez votre client ssh Putty.exe puis saisissez les différentes informations nécessaires à la connexion SSH (adresseip:port) puis allez dans le menu de gauche “Connection -> Data” et remplissez dans le bandeau “Auto-Login username” l’utilisateur ayant le droit de se connecter en ssh, ici florent. Cette étape dispensable évite de saisir l’identifiant lorsque l’on se connecte.

Puis dans le menu “Connection -> SSH -> Auth” , indiquez le chemin ou se trouve votre clé privé fichier.ppk. Nous avons fini du coté client.

Sur notre serveur SSH :

Il convient maintenant d’ajouter la clé id_rsa.pub aux clés autorisés à se connecter sur ce serveur. Pour cela rien de plus simple ! Dirigez dans le dossier de l’utilisateur ayant le droit d’utiliser SSH :

cd /home/florent/.ssh/

Puis créez le fichier authorized_keys et injectez le contenu de la clé publique préalablement générée :

touch /home/florent/.ssh/authorized_keys
cat id_rsa.pub > /home/florent/.ssh/authorized_keys

Il ne vous reste plus qu’a tester la connexion SSH avec authentification par certificat !

Un dernier mot cependant, vous pouvez si vous le désirez (sous réserve de la réussite du dernier test) désactiver l’authentification par mot de passe au service SSH. Pour cela éditez le fichier /etc/ssh/sshd_config et modifiez cette directive :

PasswordAuthentication no

Enfin redémarrez votre service ssh :

/etc/init.d/ssh restart

Vous voilà avec un service SSH sé-cu-ri-sé !

Lancer une connexion VPN en ligne de commande sur un NAS Synology

Thu, 21 Aug 2014 17:13:21 GMT

Il y a quelques mois j’ai reçu une lettre assez déplaisante de la part de l’état. J’ai reçu la première lettre d’avertissement d’HADOPI. J’avais complètement oublié de désactiver le service Download Station sur mon NAS. Résultat : les Dora l’Exploratrice que j’avais téléchargé pour ma fille sont restés en partage un long moment, m’exposant ainsi à la “riposte graduée”. Je télécharge peu mais cela m’arrive tout de même j’ai donc décidé d’investir dans une passerelle VPN chez vpnfacile.net. L’idée que j’avais était d’activer et de désactiver à heure fixe ma connexion VPN (en même temps que Download Station). Hélas cela est impossible directement sur l’interface Web Synology.

La solution est donc de partir sur un petit script (deux en fait) que nous lancerons automatiquement via CRON. Il n’y a aucun problème pour la partie Download Station, car il est possible de définir des plages d’activation du service directement dans l’interface web Synology.

La première chose à faire est de créer un script dans un endroit qui ne sera pas effacé lors d’une future mise à jour du nas :

vi /usr/OpenVpnReconnect.sh

Puis ajoutez y ces lignes :

#!/bin/sh

echo conf_id=XXXXXXXXXXX > /usr/syno/etc/synovpnclient/vpnc_connecting
echo conf_name=VPNFacile >> /usr/syno/etc/synovpnclient/vpnc_connecting
echo proto=openvpn >> /usr/syno/etc/synovpnclient/vpnc_connecting
synovpnc reconnect –protocol=openvpn –name=VPNFacile

Le conf_id peut se trouver dans le répertoire “usr/syno/etc/synovpnclient/openvpn” ; il correspond à la suite alphanumérique composant le fichier “client_XXXXXXXXXX”. Le conf_name correspond au libellé que vous avez donné à votre connexion vpn sur l’interface web Synology :

N’oubliez pas d’ajouter les droits d’exécution à votre fichier :

chmod +x /usr/OpenVpnReconnect.sh

Essayer d’exécuter votre script pour vérifier que cela fonctionne :

sh /usr/OpenVpnReconnect.sh

Afin de vérifier quelle est l’adresse publique de votre nas, utilisez cette commande :

curl curlmyip.com

Elle renvoie l’adresse avec laquelle votre NAS sera visible sur internet (celle-ci doit être différente de l’adresse publique de votre ordinateur).

Maintenant nous allons faire un second script qui va nous permettre de désactiver notre connexion VPN :

vi /usr/OpenVpnDisconnect.sh

Puis ajoutez y ces lignes :

#!/bin/sh

synovpnc kill_client

Nous le rendons maintenant exécutable :

chmod +x /usr/OpenVpnDisconnect.sh

Puis nous l’exécutons et vérifions bien que cette fois ci l’adresse ip publique de notre Nas est devenue la même que notre ordinateur.

Il ne reste plus qu’à planifier dans CRON l’heure à laquelle nous désirons activer et désactiver notre tunnel VPN :

vi /etc/crontab

Personnellement je souhaite activer mon tunnel VPN à 23h55 et le désactiver à 8h05 tous les jours de la semaine, toutes les semaines de tous…

55 23 * * * root sh /usr/OpenVpnReconnect.sh
05 8 * * * root sh /usr/OpenVpnDisconnect.sh

N’oubliez pas de relancer le service CRON afin que vos modifications soient prise en compte :

_/usr/syno/sbin/synoservicectl –restart crond
_
J’espère que cette astuce vous simplifiera la vie et vous évitera les mauvaises surprises HADOPI ;)

Problème d'inventaire avec Fog 0.32

Thu, 03 Jul 2014 09:44:12 GMT

Une chose particulière quand on travaille dans l’administration ce sont les marchés publics… Nous sommes obligé de commander ce qui a été retenu et il arrive fréquemment que les matériels commandés changent de références sans info préalable. A la base il avait été retenu comme modèle de portable un HP6560b qui a évolué vers un HP6570b et aujourd’hui un HP 650 G1… J’utilise FOG (et MDT mais pas pour ce parc) pour déployer mes machines, il a donc fallu que je retravaille mon image de référence et là : PROBLÈME !!!

Pour rappel Fog est un serveur permettant de déployer des images système par le réseau (PXE). Étant donné que j’utilise la version 0.32 de Fog (un version ancienne) je rencontre maintenant des problèmes de reconnaissance de matériels. Afin que Fog fonctionne il est nécessaire d’inventorier la machine dans une BDD. Pour cela un mini kernel est envoyé à la machine cliente en tftp afin d’exécuter l’inventaire. C’est à ce moment que je rencontre un problème : le kernel étant assez ancien il ne reconnait pas mon matériel.

Sur le serveur FOG le kernel se trouve dans /tftpboot/fog/kernel/bzImage

Après quelques recherches il se trouve que l’interface web de Fog intègre un menu proposant des kernels MAJ par la communauté supportant Fog. Il suffit donc de se rendre dans le menu “Ohter information” puis dans “Kernel Updates”.

Le kernel qui a marché pour mon HP 650 G1 est le suivant :

Kernel - 3.14.2 TomElliott

FOG ID: 1054

Date: April 27, 2014

Version: 3.14.2

FOG Type: TomElliott

Arch: 32 bit

En espérant que cette astuce puisse vous faire gagner du temps !

Le boot.ini sous Windows 7/8 ?!

Thu, 14 Nov 2013 11:06:06 GMT

On m’a sollicité cette semaine par rapport à un problème lié au boot d’une machine sur WIndows 7. En effet lorsqu’on allume la machine on a le choix au boot entre Windows 7 et un “Ram Memory Test”. Je ne sais pas trop d’où vient la seconde entrée, mais toujours est il que c’est plutôt ennuyeux étant donné que cet ordinateur doit être accessible par le grand public. D’autant plus qu’aucun compteur ne se décrémente pour la sélection. Je me suis dit “je vais régler cela en 5 sec en modifiant le boot.ini” …

En fait ce n’est pas possible pour la simple et bonne raison qu’il n’y a plus de boot.ini sur Windows 7 ! En effet celui ci a été remplacé par le BCD (Boot Configuration Data) qui n’est plus un simple fichier texte mais un “magasin” offrant davantage de fonctionnalités. Pour pouvoir modifier ce magasin il existe le programme bcdedit.exe.

Il suffit de lancer une boite de commande ms-dos en tant qu’administrateur et d’exécuter bcdedit.exe :

Lorsque cette commande est lancé sans paramètre elle liste le bootloader et les entrées associés. Il existe ensuite de nombreux paramètres pour manipulé ces données.

Celui qui m’a intéréssé était le paramètre pour supprimer une entrée (“Ram Test Disk”).

Voici la commande :

bcdedit.exe /delete “resumeobject”

Cet outil vous permettra donc de faire le ménage dans votre bootloader sous Win7/8 !

Déployer Adobe Reader à l'aide d'une GPO

Fri, 04 Oct 2013 08:56:00 GMT

L’une des choses qui m’agace le plus lorsque j’allume mon pc, ce sont les mises à jour intempestives qui nous agressent pour mettre à jour Flash, Java, Adobe Reader… J’avais donc décidé de m’occuper de ces majs sur mon parc de machines au boulot. Je n’ai pas rencontré de gros problèmes à part avec la méthode que préconise Adobe pour déployer Reader. Je suis donc parti sur un script perso que je vais déployer à l’arrêt des machines. En effet Adobe Reader devient de plus en plus lent à s’installer et plus gros en taille, ce qui agace mes utilisateurs lorsqu’ils démarrent leurs ordinateurs et doivent patienter 5min. Voici donc la solution que j’ai retenue…

Pré requis :

La version de base d’Adobe Reader (la V11 au 3/10/2013)
La dernière version du patch MUI (le 11.0.04 au 3/10/2013)
Le Adobe Customization Wizard
Le dés-installateur d’Adobe Reader “AdbeArCleaner”

Préparation :

La première chose consiste à dézipper le fichier de la v11 et à placer son contenu dans un répertoire réseau accessible à l’ensemble de votre parc. Dans ce même répertoire placez votre fichier “AdbeArCleaner.exe” et votre fichier mst qui correspond à la dernière version du patch MUI. Vous devriez avoir une arborescence comme celle-ci :

Personnalisation :

Nous allons maintenant personnaliser notre installation de manière à supprimer l’acceptation du contrat EULA, ou les majs automatiques par exemple… Pour cela installer le logiciel Adobe Customization Wizard sur votre poste puis ouvrez le. Sélectionner le fichier “AcroRead.msi” dans votre répertoire partagé (File > Open Package). Ensuite personnalisez l’installation comme bon vous semble. Voila mon template :

Personalization Options > Suppress display of EULA
Installation Options > Cliquez ici pour voir la configuration
Shortcuts > Cliquez droit sur le raccourci du bureau et choisissez “Remove”
Online Service and Features > Disable product updates

Ensuite il ne vous reste plus qu’a sélectionner “Transform” dans la barre de menu et choississez “Generate Transform”. Enregistrez ce fichier dans votre répertoire partagé.

Il y a une chose à laquelle vous allez peut-être tiquer : j’ai coché dans mon fichier de configuration “Remove all versions” et je propose en prérequis l’utilitaire d’Adobe pour désinstaller Reader. En effet j’ai rencontré un problème lorsque j’installe Adobe Reader alors qu’une version précédente existe, et ce malgré le fichier de configuration qui spécifie “Remove all versions”.

Problème : A partir d’ici vous allez pouvoir tester si votre fichier de configuration fonctionne correctement. Vous avez deux choix possible :

msiexec /i “AcroRead.msi” /q TRANSFORMS=“MyPref.mst”
Setup.exe (le contenu du setup.ini peut-être renseigner avec les paramètres de la ligne d’au dessus).

En principe tout devrait marcher correctement SAUF le langage d’Adobe Reader, ce qui est plutôt problématique (pour mes utilisateurs surtout). En effet celui ci est en anglais. Après de longues recherches je me suis apercu que le contenu de mon dossier d’installation d’Adobe Reader était dépourvu du dossier qui gère les différentes langues à savoir C:\Program Files (x86)\Adobe\Reader 11.0\Reader\Locale. Pour remédier à cela voici les étapes à effectuer :

1. Installer Adobe Reader en utilisant AcroRead.msi sans mettre en paramètre notre fichier de configuration mst.

2. Allez dans votre répertoire d’installation et copier le language qui vous intéresse. Voici le fichier fr_FR qui correspond à la V11 (je ne garantis pas qu’il fonctionne dans les versiosn futures).

3. Ouvrez à nouveau Adobe Customization Wizard et sélectionnez votre fichier AcroRead.msi. Allez ensuite dans le menu “Files and Folders”. La partie du haut représent votre ordinateur et celle du bas représente le contenu du package. Nous allons donc rajouter notre fichier de langue au package. Dans le cadre du bas placer vous ici : ProgramFilesFolder > Adobe Reader 11.0 > Reader > Locale. Puis faites un Glisser-Déposer de votre fichier fr_FR du cadre du haut sur le dossier Locale du cadre du bas :

Un message vous propose de remplacer le fichier existant. Faites un “Yes to All”. Il ne vous reste plus qu’a sauvegarder vos modfis (Save > Package) et votre installation sera désormais en français lorsque vous utiliserez votre fichier de conf mst.

**Script :
**

Je ne vais pas trop rentrer dans les détails de mon script. En gros je suis sensé avoir un fichier texte sur ma machine cible qui contient les logiciels que je déploie via mon script. Mon script commence par vérifier si celui si existe. Si celui-ci n’existe pas alors il désinstalle d’hypothétiques anciennes versions de Reader et installe la V11 et applique ensuite la dernier patch. SI celui-ci existe il vérifie ce qui est installé et avise en fonction.

Voila mon script :

set UNC=\\partage\Deploy\AdbeRdr
set Last=AdbeRdrUpd11004
set Base=AcroRead11000

c:
cd c:\Windows\
if exist install.ini (
    goto Check
) else (
    echo. 2>install.ini
    goto InstallBase
)

:Check
find “%Base%” c:\Windows\install.ini
if %ERRORLEVEL% equ 0 goto CheckLast
if %ERRORLEVEL% equ 1 goto InstallBase
if %ERRORLEVEL% equ 2 goto End

:CheckLast
find “%Last%” c:\Windows\install.ini
if %ERRORLEVEL% equ 0 goto End
if %ERRORLEVEL% equ 1 goto InstallLast
if %ERRORLEVEL% equ 2 goto End

:InstallBase
%UNC%\AdbeArCleaner.exe /silent /product=1 /cleanlevel=1 /scanforothers=1
%UNC%\Setup.exe
echo %Base% >> c:\Windows\install.ini
goto CheckLast

:InstallLast
msiexec.exe /update %UNC%\%Last%_MUI.msp /qb /norestart TRANSFORMS=“MyPref.mst”
echo %Last% >> c:\Windows\install.ini
goto End

:End
echo Fin

Il est sans doute sujet à amélioration, je suis ouvert à toute proposition.

N’oubliez pas de placer votre script dans un partage accessible à tout le monde.

GPO :

Enfin il nous reste plus qu’a créer notre GPO. Pour cela ouvrer votre mmc lié à la gestion des stratégies de groupes. Puis dans cliquez droit sur “Objets des stratégies de groupe” et sélectionner Nouveau. Nommez votre stratégie, puis modifiez la. Allez dans Configuration ordinateur > Paramètres Windows > Scripts puis double cliquer sur Arrêt du système et ajouter l’emplacement de votre script.

Validez vos modification et assignez votre GPO en la liant à l’UO qui vous intéresse > cliquez droit et “Lier un objet de stratégie de groupe existant”.

Votre script devrait s’appliquer automatiquement à l’arrêt des machines de votre parc.

Mise en place d'un VPN IPSec avec un Netasq U70

Mon, 16 Apr 2012 13:26:28 GMT

Cet article a pour but d’expliquer comment configurer le routeur Netasq U70 (configuration de l’autorité de certification, mise en place du tunnel et configuration du pare-feu) et le client IPSec gratuit Shrew Soft afin d’établir un tunnel sécurisé entre ces deux éléments.

I.Configuration du routeur Netasq U70 :

I.1 - Configuration de l’autorité de certification (PKI) :

Il convient dans un premier temps de créer notre PKI interne qui servira à fournir les certificats aux différents utilisateurs du VPN. Pour cela nous allons dans le menu de gauche : PKI > Général

Nous utiliserons l’assistant de création de PKI en cliquant sur le bouton du même nom.

Nous allons ensuite détailler les différentes informations de notre PKI :

Une fois la page remplie, nous pouvons passer à l’étape 2 en cliquant sur Suivant. Nous allons ensuite définir un mot de passe associé à la CA. Celui-ci est important car il vous sera demandé à chaque création de certificat.

Nous allons personnaliser la validité de notre autorité de certification CA et des certificats utilisateurs ainsi que la complexité de leurs clés. J’ai choisis de laisser les valeurs par défaut.

Aucun outil particulier n’a besoin d’accéder à la CRL, nous ne définirons donc aucun lien vers celle-ci. En effet, lors de l’échange de certificat la CRL est consulté de manière locale sur le routeur, afin de vérifier si le certificat est bloqué ou non.

Enfin nous pouvons spécifier à l’étape 5 si nous permettons aux utilisateurs d’effectuer eux-mêmes la demande de certificat. Dans notre cas de figure ce paramètre est inutile, nous ne le cochons donc pas.

Notre PKI est maintenant fonctionnelle et peux délivrer des certificats aux utilisateurs.

I.2 - Création de l’utilisateur LDAP :

Nous allons créer l’utilisateur dans l’annuaire LDAP du routeur Netasq et lui associer un certificat. Cela nous permettra d’exporter le certificat sur la machine cliente et d’avoir dans le rapport syslog un nom de connexion VPN plus précis sur l’utilisateur connecté.

Cliquons dans le bandeau de gauche sur le menu Objets. Une nouvelle fenêtre s’ouvre. Cliquons sur le bouton Nouveau et choisissons Utilisateur :

Dans cette fenêtre remplissez le nom, l’identifiant (pour Florent Fragnol -> ffragnol par exemple) le prénom ainsi que l’email et plus si vous le désirez. Ensuite cliquons sur « Terminer ».

Une fenêtre récapitulant les informations saisies s’ouvre. Allons dans l’onglet accès et cochons comme VPN autorisé le VPN IPSec sans modifier la clé.

Plaçons nous dans l’onglet certificat puis cliquons sur « Créer le certificat ».

Une fenêtre apparait nous demandant le mot de passe de la CA précédemment définit, et nous demande de choisir un mot de passe associé au certificat de l’utilisateur. Il est fortement conseillé de choisir un mot de passe complexe. Ce mot de passe sera demandé à l’utilisateur dès qu’il établira une connexion avec le réseau distant.

Un message nous avertira que la création du certificat a été effectuée. Il ne nous reste plus qu’à exporter le certificat en cliquant sur le bouton « Exporter le certificat ». Puis nous choisirons le format d’export PKCS12.

Nous disposons donc d’un certificat « PrenomNom.p12 » qui contient les informations telles que le certificat X509 d’identification de l’utilisateur, une clé publique et une clé privé. Ce fichier sera à transférer manuellement sur le poste de l’utilisateur vers cet emplacement : « C:\Program Files\ShrewSoft\VPN Client\certificates ».

I.3 - Création du tunnel IPSEC :

Nous allons maintenant créer notre tunnel IPSec nous permettant de connecter un ordinateur nomade au réseau de l’entreprise. Naviguons dans le bandeau de gauche pour aller sur le menu VPN > Tunnels IPSec :

Étape 1 = Une fenêtre s’ouvre nous proposant de sélectionner un slot VPN. Nous sélectionnerons un slot vide et éditerons celui-ci avec le bouton « Editer ».
Un assistant s’ouvre nous guidant dans le processus de création de tunnel IPSec. Nous donnerons dans un premier temps un nom à notre tunnel IPSec puis nous choisirons un modèle de protection. Par défaut Netasq propose le modèle « Good Encryption » qui d’après eux est le meilleur rapport sécurité/rapidité, nous choisirons celui-ci :

Étape 2 = cette deuxième étape nous propose de choisir le type de tunnel. Nous avons le choix entre deux tunnels dynamique (le modèle statique étant obsolète). Ces deux types de tunnels sont basés sur une négociation dynamique des paramètres des tunnels VPN grâce au protocole IKE. Nous choisirons le second mode Dynamique qui consiste en un échange de certificats, plus sécurisé que le premier. Nous n’oublierons pas de cocher la case « Mode avancée » qui va nous permettre de spécifier en extrémité « Any », nos clients étant des nomades avec une IP dynamique.

Étape 3 = cette étape va nous permettre de définir les extrémités de notre tunnel. Nous choisirons au niveau de notre interface locale, l’interface qui communique avec l’extérieur (internet, le réseau dit « non-sur ») c’est-à-dire l’interface « Firewall_Internet_Neuf » qui a été configuré au préalable avec les paramètres PPOE (notre Neufbox étant en mode bridge). Le correspondant à l’autre bout de l’extrémité étant un nomade, avec une adresse IP dynamique nous préciserons un objet de type « Any » :

Étape 4 = a partir de cette étape, nous allons devoir définir les extrémités du trafic. Nous allons donc spécifier le réseau que nous voulons atteindre à savoir le réseau 172.16.0.0, qui est définit sur l’interface Network_IN. Nous aurions pu être plus restrictif en spécifiant également une seule machine. L’autre extrémité sera encore une fois régler sur « Any », notre poste nomade ayant une adresse IP dynamique.

Cliquez ensuite sur suivant puis sur « Terminer ». Une nouvelle fenêtre s’ouvre récapitulant les informations déjà entrées ainsi que d’autres à définir. Nous devons maintenant générer la clé privée du Netasq. Cliquons sur « Choisissez un certificat » :

Dans la fenêtre qui s’ouvre nous allons cliquer sur le bouton « Certificat interne » afin de générer une clé privée propre au Netasq.

Dans la fenêtre qui vient de s’ouvrir cliquons sur le bouton « Créer un certificat VPN ». Le mot de passe de la CA nous sera demandé. Une fois la création effectuée, un message nous avertira du bon déroulement de l’opération.

Nous pouvons apercevoir la clé associée à cette extrémité du tunnel :

Nous validons cet écran en cliquant sur le bouton « OK ». Nous allons ensuite éditer quelques options afin que notre tunnel puisse s’établir correctement. Pour cela nous allons cliquer sur le bouton « Configuation avancée ».

Il suffit de cocher l’option « Envoi du certificat » de manière à ce que les deux interlocuteurs puissent s’échanger leur clé publique. Sans cette option cochée, le tunnel ne peut s’établir.

Ensuite, nous cliquons sur le bouton «Paramètres avancés» en bas de cette fenêtre. Une nouvelle fenêtre apparait où il faudra cocher « Faire confiance à la PKI interne », puis cliquez sur OK.

Il le nous reste plus qu’à valider le paramétrage de notre tunnel en cliquant sur « Envoyer » puis confirmer en cliquant sur « Oui ». N’oublions pas d’activer votre slot VPN en cliquant sur « Activer » :

Notre tunnel est maintenant configurer, ainsi nos utilisateurs pourront s’y connecter. Cependant, notre pare-feu bloque par défaut les ports nécessaires à la négociation des éléments de sécurité ainsi que le trafic des données via notre tunnel VPN. Pour un tunnel de Passerelle à Passerelle ces règles peuvent être configurées de manière implicite par notre routeur (page 280 sur la documentation du Netasq), mais notre tunnel pointe vers un objet Any, nous allons donc devoir créer des règles manuellement.

I.4 - Définition des règles du pare-feu Netasq :

Nous allons dans un premier temps devoir autoriser le trafic provenant de notre machine nomade, soit « Any » vers notre port recevant le flux internet à savoir Firewall_Internet_Neuf.

Les premiers échanges ayant lieu sont les phases de négociation des paramètres de sécurité, nous autorisons les règles suivantes :

Le protocole de transport utilisé est UDP pour l’isakmp.

Notre réseau se trouvant derrière un routeur nous allons devoir utilisé le NAT Transversal qui consiste à rendre compatible IPSec derrière un NAT. Un premier échange est envoyé avec le protocole ISAKMP sur le port 500, lors du retour du paquet en question notre client compare un hash de l’adresse IP et des ports afin de voir s’ils sont identiques. S’ils sont différents c’est que l’adresse ou le port a été translaté. Dans ce cas de figure l’échange se fera en utilisant le NAT-T sur le port 4500 d’où l’utilité d’ouvrir le port 500 (isakmp, Règle 2) et 4500 (isakmp_natt, Règle 3).

Enfin il faut également veillez à autoriser nos trames cryptés ESP. Nous autoriserons donc le protocole vpn-esp en provenance d’Any vers Firewall_Internet_Neuf (Règle 4) et également l’inverse du Firewall_Internet_Neuf vers Any (règle défini implicitement par la Règle 10).

A ce stade les phases de négociations les sécurités et les échanges avec le protocle ESP sont maintenant autorisés, cependant aucun trafic n’est autorisé sur notre interface IPSec. Nous allons donc autorisé le trafic via notre interface logique IPSec venant de la source « Any » vers la destination de notre réseau internet soit Network_IN (Règle 1). Le trafic devrait également être possible du réseau interne vers « Any » via l’interface IPSec, règle autorisée de manière implicite par la Règle 10.

A ce stade la configuration du coté de notre routeur est effective et fonctionnelle. Nous allons maintenant pouvoir entamer la configuration coté client.

II.Configuration du client Shrew Soft :

Procurez vous dans un premier temps le client Shrew soft à cette adresse : http://www.shrew.net/download/vpn (les différentes versions du client sont en bas de page). Après avoir installé le logiciel nous allons lancer Access Manager qui permet comme son nom l’indique, de configurer notre (ou nos) connexion VPN IPSec.

Nous allons maintenant cliquer sur le bouton « ADD » afin d’ajouter une nouvelle connexion :

Une nouvelle fenêtre s’ouvre :

Nous allons y remplir l’adresse publique de notre routeur (en ce qui nous concerne notre nom de domaine DynDNS) ainsi que le port par défaut 500 (ISAKMP). Nous désactiverons l’auto-configuration et nous utiliserons notre carte réseau (et non une virtuelle) pour établir la connexion.

Ensuite allez dans l’onglet Client :

Nous activons le NAT Transversal en laissant le port par défaut, puis nous désactiverons la fragmentation IKE dispensable dans notre cas. Enfin, nous laisserons les autres paramètres par défaut. Allez ensuite dans le Name Résolution :

Afin d’avoir une résolution des noms de machines du réseau local nous activerons le DNS en précisant le suffixe dns : etudarmor.lan. Ceci nous permettra d’utiliser les mêmes scripts déjà établis, nous évitant de les refaire avec les @ IP des machines. Passons maintenant a l’étape Authentification en cliquant sur l’onget du même nom :

La méthode d’authentification est Mutual RSA (échange de certificats). Ici nous allons déterminer l’identification locale, qui identifie le nomade. Cette identification doit correspondre à une entrée dans l’annuaire LDAP précédemment défini. Nous choisirons donc le type d’identification « ASN.1 Destinguished Name » et cochons l’option « Use the subject in the client certificate ».

Ensuite nous allons configurer l’identité distante en cliquant sur « Remote Identity » :

Nous allons définir la même identité que nous avons défini plus haut lors de la configuration du tunnel, à savoir ASN.1. Passons maintenant à l’onglet « Credentials » :

Nous allons sélectionner trois fois notre certificat P12 se trouvant dans C:\Program Files\ShrewSoft\VPN Client\certificates\. En effet, ces trois informations se trouvent toutes dans le même fichier p12.

Paramétrons ensuite les éléments de sécurité de la phase 1 pour qu’ils correspondent à ceux du tunnel VPN (nous avons gardé ceux par défaut, mais il est tout à fait possible de changer ceux-ci, tant qu’ils correspondent avec la configuration sur le Netasq) :

Dans l’onglet de la phase 2 nous procédons de la même manière que la phase 1 :

Enfin, allons dans l’onglet Policy :

Nous désactivons la case « Obtain Topology Automatically or Tunnel All » et spécifions le réseau à atteindre : 172.16.0.0/16 Puis nous choisirons une niveau de politique unique pour la SA.
Notre client est maintenant configuré, il ne nous reste plus qu’à sauvegarder les différents paramètres renseignés en cliquant sur Save.
La connexion est maintenant créée :

Il ne nous reste plus qu’à la sélectionner et à cliquer sur « Connect », une fenêtre s’ouvre alors :

Cliquons sur « Connect » pour établir la liaison avec le réseau distant. Le mot de passe du certificat nous sera demandé, assurant une sécurité supplémentaire.

Si tout se déroule bien il apparaitra ceci dans le log de la fenêtre :

Si la négociation est effective nous verrons dans l’onglet Network ceci :

Une SA est bien établie et notre statut est connecté. Il ne vous reste plus qu’à nous connecter au réseau local.