Ubuntu Touch – Mise-à-jour de OTA-3 à OTA-4

Ayant en ma possession une phablette (Meizu MX4), j’en ai profité pour mettre à jour le système et de passer de la version installée d’origine en 15.04 à 16.04, grâce au super boulot fait par l’équipe d’Ubports qui continue de maintenir le système que Cannonical a délaissé.

Cette mise-à-jour devrait passer comme une lettre à la poste, mais ce n’est pas le cas. Sinon, je n’aurai pas été obligé d’écrire ce blog. Le problème que j’ai rencontré, c’est qu’une fois l’installeur Ubports lancé, le téléphone a redémarré en mode de récupération (recovery mode), puis y est resté figé jusqu’à ce que je redémarre le téléphone.


Si je lance le téléphone en mode recovery et qu’il est pas branché à quoi que ce soit, le même problème se présente.

Plusieurs solutions ont été présentées sur le forum de Uports, dont je vais détailler plus bas. D’ailleurs, j’ai copié la copie d’écran ci-dessus à partir du topic « [solved] Mx4 – Installer blocked at « waiting for recovery mode »

 

Je dois avouer que je ne sais pas à quel moment j’ai réussi à débloquer la situation, mais au final la mise-à-jour s’est bien passé après avoir essayé toutes les suggestions que j’ai trouvées sur internet. De plus, je n’ai pas le temps ni l’envie de m’amuser à flasher le téléphone pour installer la version originale de Ubuntu puis refaire la manipulation. Je vous laisse le soin de laisser des commentaires en précisant ce qui marche dans votre cas.

 

I. Mise-à-jour avec Ubports

La méthode pour mettre Ubntu touch à jour est décrite sur cette page « How to manually upgrade from OTA-3 to OTA-4« . J’ai effectué toutes les manipulations sur une machine qui tourne avec Debian, qui est le seul OS qui ne m’a pas posé de soucie durant toute l’étape de la mise-à-jour.

Tout comme M et Mme Michu, j’ai juste suivi la documentation sur les étapes à suivre pour la mise-à-jour.

J’ai donc commencé par télécharger l’installeur Ubports, puis le lancer et voir ce qu’il en est.

Mon appareil a bien été détecté. Par contre, la copie d’écran ci-dessous, je l’ai effectuée après la mise-à-jour.

Initialement, à la place du bouton « Install », j’avais l’option « Switch to Ubports« . Ce n’est qu’une fois que la mise-à-jour terminée que je n’ai eu droit au bouton Install après avoir reconnecté mon téléphone à Ubports.

Sur cette page, on vous rappelle qu’il faut activer le mode développeur (System Settings > About > Developer Mode) du téléphone si ce n’est pas encore fait.

Cliquer ensuite sur « Change options ».
Comme Channel, sélectionner 16.04/stable, et ne surtout pas cocher « wipe settings » pour ne pas effacer toutes les données du téléphone. A moins que c’est ce que vous souhaitez.

Ensuite, après avoir cliqué sur « Switch to Ubports« , j’ai l’impression que mon ordinateur n’arrive pas à communiquer avec le téléphone. Au niveau de l’installer j’ai un message « Waiting for recovery mode », par contre le téléphone a bien redémarré en mode recovery, mais affiche une barre qui ne progresse pas, comme sur l’image au début de ce topic.

Comme je ne savais pas vraiment quoi faire à ce niveau, j’ai fermé l’application Ubports, puis redémarré le téléphone.

Je ne pense pas que les manipulations que j’ai effectué ci-dessous contiennent la solution à ce problmème, mais à un moment donné, et après avoir effectué une énième tentative de mise-à-jour, j’ai juste redémarré le téléphone sans fermer l’application Ubports en ayant gardé le cable USB connecté. Puis « miracle », l’application Ubports sur mon ordinateur commence à envoyer des paquets de mise-à-jour vers le téléphone que je précise, qui a juste redémarré en mode normal.

 

II. Mise-à-jour via SSH

1. OpenSSH Client

Il est possible de mettre à jour le système en mode ligne de commande sans avoir à installer l’outil Ubports.

Pour celà, il nous faut installer plusieurs outils nécessaires à la gestion d’un téléphone android: openssh, adb et Android SDK.

Pour établir une connection SSH entre votre ordinateur (côté client) et le téléphone (côté serveur), il vous faut créer une paire de clés:

  • Une clé privée à ne jamais partager avec qui que ce soit et
  • Une clé publique qu’il faut ensuite copier dans le répertoire de téléphone

 

J’ai déjà expliqué comment créer une connection SSH dans l’article sur la sécurisation d’une Raspberry Pie, mais une piqûre de rappel ne fera pas de mal.

Sur votre ordinateur, vérifier que le paquet openssh-client est bien installé. Si ce n’est pas le cas, il faut le faire.

mon@ordi$ dpkg -l | grep ssh
mon@ordi$ sudo apt-get install openssh-client

Générer une paire de clés avec l'utilitaire SSH keygen.
mon@ordi$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/matakasi/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

N’ommetez pas la passphrase, qui est une forme de sécurité supplémentaire.

Les clés générées devraient se trouver dans le répertoire ~/.ssh:
– clé privée: id_rsa (vous devez ne jamais fournir cette clé à personne)
– clé publique: id_rsa.pub.
Vérifier que vous avez bien les deux clés (id_rsa et id_rsa.pub) dans le répertoire de votre ordinateur.

~$ cd

~$ ls .ssh
config config.bak id_rsa id_rsa.pub known_hosts known_hosts.old

Une fois que vous avez les clés, il ne reste plus qu’à envoyer une copie de la clé publique vers le téléphone pour que l’ordinateur puisse se connecté à l’appareil.

 

2. ADB (Android Debug Bridge)

Avant de parler des différents outils, il faut comprendre comment un système Android fonctionne.

Il faut savoir que sur système Android les trois partitions suivantes sont présentes:

  • BootLoader (chargeur de démarrage)
    C’est un script qui se lance avant même que le système d’exploitation se lance. Je dois rajouter qu’il n’y a pas vraiment de bootloader type sur un système Android, puisque chaque fabriquant de téléphone fournit une version spécifique du bootloader pour chaque carte mère. Par sécurité, le bootloader sur chaque téléphone Android n’est pas accessible par défaut.Appuyer sur le bouton « Power » et sur la touche du volume vers le Bas pour accéder au mode Bootloader. En bas de l’écran du téléphone vous devrez avoir « FASTBOOT mode… ».L’installation de l’outil Android SDK est nécessaire pour pouvoir accéder au bootloader.
  • Recovery
    Le mode recovery est le mode utilisé manipuler et pour mettre à jour la partition Android ROM.A bootable program on an Android flash memory partition that is used to perform a factory reset or restore the original OS version. In order to install a different OS version (a different ROM), the stock recovery image must be replaced with a custom version such as ClockworkMod Recovery. After rooting the Android, utilities such as ROM Manager install the custom recovery, which is then used to install the custom ROM.Appuyer sur le bouton « Power » et sur la touche du volume vers le Haut pour accéder au mode Recovery. En bas de l’écran du téléphone vous devrez avoir « Recovery mode… ».L’installation de l’outil ADB est nécessaire pour pouvoir accéder au mode recovery.
  • Andoid ROM
    Partition dans laquelle est installée le système d’exploitation, dans notre cas Ubuntu Phone. Par contre, le système Android n’a pas entièrement disparu puisqu’il est placé dans un conteneur LXC pour que le système Ubuntu Touch puisse continuer à communiquer avec, afin de pouvoir bénéficier de tous les pilotes Android pour les différents matériels (carte réseau, caméra, etc.).

Maintenant qu’on a vu comment accéder aux différentes partitions ainsi que les différents outils nécessaire pour les manipulations, il est temps de voir ce que l’on peut faire avec.

Au fait nous n’avons besoin que de l’outil ADB pour la suite, par contre l’outil Android SDK sera automatiquement installé avec ADB.

Lancer l’installation de ADB.

~$ sudo apt install adb

Brancher votre appareil à l’ordinateur, puis vérifier qu’il est bien reconnu.

~$ adb devices
List of devices attached
75HXXXXXXXXX

Créer un dossier .ssh dans le dossier /home/phablet du téléphone.

~$ adb shell mkdir /home/phablet/.ssh

Envoyer une copie de votre clé publique de l’ordinateur vers le téléphone.

~$ adb push ~/.ssh/id_rsa.pub /home/phablet/.ssh/authorized_keys

Modifier les permissions et les groupes des dossiers et sous-dossiers de .ssh

~$ adb shell chown -R phablet.phablet /home/phablet/.ssh

~$ adb shell chmod 700 /home/phablet/.ssh

~$ adb shell chmod 600 /home/phablet/.ssh/authorized_keys

Récupérer l’adresse IP du téléphone à partir du System Settings>Wi-fi> »Votre_réseau_wifi »>IP address (dans mon cas, 192.168.1.6), puis connectez vous en SSH au téléphone.

~$ ssh phablet@192.168.1.6
Welcome to Ubuntu 15.04 (GNU/Linux 3.10.35+ armv7l)

* Documentation: https://help.ubuntu.com/

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

Pour avoir la liste des canaux disponible,

phablet@ubuntu-phablet:~$ sudo system-image-cli –list-channels
[sudo] password for phablet:
b'75HXXXXXXXXX\n'
Available channels:
15.04/devel
15.04/rc
15.04/stable
16.04/community/walid/devel
16.04/devel (alias for: ubports-touch/16.04/devel)
16.04/rc (alias for: ubports-touch/16.04/rc)
ubports-touch/15.04/devel
ubports-touch/15.04/rc
ubports-touch/15.04/stable
ubports-touch/16.04/devel
ubports-touch/16.04/rc
ubports-touch/16.04/stable
ubports-touch/legacy
ubuntu-touch/devel
ubuntu-touch/devel-proposed
ubuntu-touch/devel_rc-propoed
ubuntu-touch/devel_rc-proposed
ubuntu-touch/devel_stable
ubuntu-touch/rc-proposed
ubuntu-touch/stable
phablet@ubuntu-phablet:~$

 

Pour la mise-à-jour vers 16.04 en version stable, il faut utiliser le canal 16.04/stable au lieu de ubports-touch/16.04/stable. Apparement, la liste de canaux n’est pas vraiment à jour.

phablet@ubuntu-phablet:~$ sudo system-image-cli -vvvv --switch 16.04/stable

L’option -vvvv permet d’avoir la mise-à-jour en mode verbeux.

Et voilà, tout devrait être bon maintenant.

 

Sources

How to manually upgrade from OTA-3 to OTA-4
[ADB | FASTBOOT | LINUX COMMANDS] BootLoader, Kernel, Recovery, ROM, Root, Backup
[solved] Mx4 – Installer blocked at « waiting for recovery mode »

 

Publicités

[Windows] MRemoteNG – Gestionnaire de connexions distantes

En tant qu’administrateur, à un moment ou à un autre, on n’a d’autre choix que d’utiliser le matériel proposé par l’entreprise. Généralement, on vous met dans les bras un PC avec Windows installé dessus. Je ne raconte même pas la galère que j’ai eu à utiliser Windows 10. Cà n’a rien à avoir avec la facilité d’utilisation de Windows XP! Géniale la comparaison, n’est ce pas. Trêve de plaisanterie.

Dans cet article, je vais vous présenter un outil open source, et qui est super génial pour administrer vos serveurs. Je ne vous présente plus MRemoteNG si vous connaissez déjà. Je vais vous proposer ensuite quelques extensions qui me sont très utiles.

Bien que Unity n’est plus développé par Canonical, c’est l’interface graphique par défaut avec la version 16.04 LTS. Quand la version 18.04 sera disponible, on verra si c’est toujours galère de s’y connecter en RDP.

Pour ne pas avoir à faire trop de manipulation virer, ou mettez de côté GNOME et UNITY. XFCE sera notre interface graphique de choix, et plus particulièrement pour un accès à distance avec le moindre effort.

I. Sur la machine distante, Ubuntu

Installer xRDP et XFCE

sudo apt install xrdp xfce4
echo xfce4-session >~/.xsession
cp /etc/xrdp/startwm.sh /etc/xrdp/startwm.sh.bak

Remplacer « . /etc/X11/Xsession » par « startxfce4 » dans le fichier /etc/xrdp/startwm.sh

sed -e "s;. /etc/X11/Xsession;startxfce4;" /etc/xrdp/startwm.sh

Redémarrer le service xRDP

sudo service xrdp restart

Activer le partage de bureau dans les Préférences de bureau distant.

Noter votre adresse IP pour l’accès à distance.

hostname -I

 

II. Sur la machine locale, Windows

Installer mRemoteNG et créer une nouvelle connection avec les informations de votre machine distante.


La puissance de cet outil réside dans le fait que, non seulement il supporte à la base plusieurs types de protocols (SSH, RDP, etc.), mais aussi on peut y lier des outils externes (NMAP, WinSCP, etc.).

Dans cet exemple, je vais rajouter Zenmap GUI, qui est l’interface graphique de Nmap. Dans un premier temps, installer Nmap puis dans MRemoteNG, sélectionner Outil>Outils Externe>Nouveau pour configurer le nouvel outil.

Pour Zenmap,


Display Name: Zenmap GUI
Filename: C:\Program Files\Nmap\zenmap.exe (chemin d’accès vers le fichier zenmap.exe)
Arguments: -p « Quick scan plus » -t %Hostname%
Try to Integrate: V (cochée)

 

Sources:

How to Setup A Ubuntu Remote Desktop
How to use xRDP for remote access to Ubuntu 14.04
3 Tips for the mRemoteNG Remote Connections Manager
Common External Tool Configurations
MRemoteNG – multi-gestionnaire de connexions distantes
Downloading Nmap

 

Migration de VMs VirtualBox vers Proxmox

Comment migrer des machines virtuelles de VirtualBox vers Proxmox?

Je vais essayer de vous aider à le faire, à travers ce chapitre. Ce n’est pas difficile à faire, une fois qu’on a compris le principe.

I. Préparation des VMs sous virtualbox

« Clonezilla est un logiciel libre de restauration de données, de clonage de disque, et de création d’image de disque. » (wikipedia)

Voici un petit récapitulatif des matériaux et logiciels utilisés pour cette migration.

– Serveur Physique (HP Proliant Gen 8, OS: Proxmox)
– Machine hôte (Macbook Pro 2010, OS: Debian, serveur SSH activé, Virtualbox)
– VMs (OS: Debian) à migrer
– Live CD (clonezilla-live-2.5.0-25-amd64.iso)

1. Connection SSH

Noter l’adresse IP de la machine hôte, puisqu’on va s’en servir pour une connection SSH à partir de la machine virtuelle, ainsi qu’à partir de Proxmox.

20170522-074707

De ce fait, vérifier que le serveur SSH est installé sur votre ordinateur. Si ce n’est pas le cas, faites le.

# apt-get install openssh-server

Puis vérifier que SSH est activé.

# service ssh status
# service ssh start

Ensuite, configurer ssh pour autoriser l’accès à partir de n’importe quel machine de votre réseau.

$ sudo vim /etc/ssh/sshd_config
PasswordAuthentication yes
PermitRootLogin yes

$ sudo service ssh restart

Notez bien que cette étape n’est pas la bonne pratique à utiliser avec SSH. Pour plus d’information sur comment sécuriser votre accès SSH, je vous renvoir à ce chapitre.

2. Préparation des machines virtuelles

Démarrer la machine virtuelle à migrer, puis vérifier que vous pouvez accéder à la machine hôte en SSH.

Si telnet n’est pas installé sur cette VM, les deux méthodes suivantes permettent de vous confirmer si le port 22 (SSH) est ouvert ou non.

$ cat < /dev/tcp/192.168.1.10/22
SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
^C

$ nc -zv 192.168.1.10 22
[192.168.1.10] 22 (ssh) open

Arrêter ensuite la machine virtuelle pour la suite.

3. Clonezilla

Créer un dossier du même nom que l’outil utilisé, Clonezilla par exemple, dans lequel vous allez placer les images créées par cet outil. Ceci vous permettra d’y accéder plus tard en SSH, en tant qu’utilisateur et non en tant que root.

$ mkdir /home//Clonezilla

Télécharger ensuite le live CD de clonezilla que vous pouvez trouver ici, puis démarrer la machine virtuelle à migrer avec.

J’ai omis certaines captures d’écran, dont les options sont restées par défaut, afin de ne garder que l’essentiel.

Une fois arrivé au niveau de la page « Mount Clonezilla Image directory » choisissez SSH pour accéder à la machine hôte, pour y placer l’image créée par Clonezilla.

Choisissez le mode DHCP afin de ne pas vous prendre la tête à configurer la carte réseau de cette VM.

Taper ensuite l’adrese IP de la machine hôte.

Et enfin, entrez le chemin pour accéder au dossier /home//Clonezilla créé précédement.

Taper « yes » pour continuer, puis entrer le mot de passe de l’utilisateur.

La connection SSH étant établi, Clonezilla peut maintenant se lancer dans la création d’une copie de l’image du VM. Le mode Beginner (débutant) est amplement suffisant. Par contre pour clôner le VM, il faut choisir le mode Expert, que nous allons voir plus loin dans ce chapitre. Donc patience!

Pour le nom de l’image, je vous conseille de choisir quelque chose qui peut vous indiquer la nature du VM, et plus particulièrement si vous avez plusieurs VMs à migrer, afin de savoir laquelle fait quoi.

Une fois l’image créée, il n’y a aucune raison d’allumer la machine virtuelle dans Virtualbox.

Au niveau de l’écran suivant, taper sur la touche « Entrée »pour continuer, puis entrer « y ».

Et voilà, la création de l’image du VM est lancée. La procédure peut prendre du temps en fonction de la taille du disque à copier.

Entre temps, vous pouvez vous occuper de la création de la machine virtuelle sous Proxmox.

II. Préparation de la machine sous Proxmox

Dans le disque local de Proxmox, télécharger une copie de du live CD de clonezilla, qu’on va utiliser pour démarrer la nouvelle machine virtuelle.

Concernant cette nouvelle VM, il faut qu’elle ait la même taille auquel il faut ajouter quelques Go d’espace supplémentaire.

Vérifions dans ce cas, les informations de notre VM dans le Virtualbox.

Comme vous pouvez le voir, ma VM fait 20Go. Il va falloir que je créee une machine avec Promox, de 21Go au moins.

1. Préparation de la nouvelle VM

Créer une machine virtuelle en cliquant en haut à droite sur « Create VM ».

Dans l’écran de création du VM, vous avez plusieurs onglets, dont le premier vous demande de renseigner les informations concernant cette nouvelle machine(Nom de la machine, etc.).

Dans l’onglet « General », il n’y a que le nom du VM à remplir. Cette case peut être laissée vide, mais Proxmox va choisir un nom générique pour votre machine.

Dans l’onglet OS, choisissez le système d’exploitation ou la version du noyau pour les machines sous linux.

Dans l’onglet CD/DVD, sélectionner l’image ISO du live CD de Clonezilla.

Dans l’onglet « Hard Disk »,
– Choisissez l’option VirtIO
– Valider la taille du disque de la VM (20Go + 1Go)
– Cocher la case « Discard » si vous utilisez des disques physiques SSD. Si ce n’est pas le cas, donc nul besoin de cette option

Dans l’onglet CPU, l’option par défaut me convient.

Dans l’onglet Memory, j’ai choisi une taille de mémoire moins importante que celle de ma machine virtuelle dans virtualbox.

Dans l’onglet Network, j’ai gardé les informations par défaut.

Pour information, VirtIO est l’équivalent du GuestOS avec la technologie de vmware.

Et voilà, la VM est prête. Si plus tard, vous n’êtes pas satisfait de votre configuration, vous pouvez toujours modifier les informations des VMs (taille de la mémoire, nombres de processeurs, etc.) comme avec Virtualbox.

2. Migration du/des VMs

Lancer la VM dans proxmox.

Pareil que dans la première étape de création de l’image, connectez vous en SSH à la machine hôte, pour récuperer l’image de la VM créée par Clonezilla.

Puis passer en mode expext pour installer cette image vers la nouvelle destination.

Choisissez ensuite l’option « restoredisk » qui, comme son nom l’indique, permet de restaure un disque. Ce n’est pas tout à fait notre cas, mais ceci pour vous dire que c’est la même procédure à suivre pour restaurer un disque à partir d’une sauvegarde, ou pour la migration de VMs.

Ensuite, il vous sera posée la question de quelles VMs vont être restaurer. D’où l’intérêt d’avoir choisi un nom d’image bien spécifique afin de pouvoir choisir le bon parmi la liste des images dans le même dossier.

Vous ne devriez pas avoir à choisir l’emplacement de la cible.

Dans cette partir, laisser les options choisis par défaut.

De même pour la suivante.

Finalement, choisissez de redémarrer la VM une fois la migration terminée, et de vérifier que tout est bon.

Et voilà, la migration commence.

Taper « y » pour continuer.


Une fois le processus de migration terminée, la VM va redémarrer.

Si tout s’est bien déroulé, la VM devrait démarrer sans problème.

Je n’ai eu aucun problème pour migrer les VMs tournant sous Debian, comme vous pouvez le voir ci-dessus. Par contre, j’ai eu droit à un écran noir avec la machine tourant sous Manjaro. Je n’ai pas chercher à comprendre d’où vient le problème, mais je préfère prévenir au cas où.

Sources

SSH – Debian wiki
How to user SSH to connect to a Remote Server in Ubuntu
Sécuriser votre rpi
Test if a port on a remote system is reachable (without telnet)
Proxmox « no backup », « discard », « iothread »
Proxmox options for Hard disk and CPU tab
how to use clonezilla to backup hard drive and create recovery iso image
restore an image of a hard drive using clonezilla

Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Ce chapitre n’a pour but que de vous faire un petit résumé des différentes étapes à partir de l’installation de Owncloud sur un Raspberry Pi, jusqu’à avoir un server fonctionnel.

Je vais aussi en profiter de cette partie pour tester la dernière version en date de Owcloud.

Pour rappel, nous avons besoin de:

  1. Matériel:

    – Raspberry Pi 2 B
    – Carte micro SD, Classe 10
    – Câble HDMI avec un moniteur (écran télé) qui supporte le HDMI
    – Câble Ethernet

  2. Firmware:

    – Owncloud 9.1.3
    – Raspbian 8.0

  3. Configuration:

    – Adresse IP Publique
    – Adresse IP Privée statique (LAN) pour le RPi
    – Nom de domaine (NetLibre, nsupdate)
    – Certificat LE (Lets encrypt)

Ne vous attendez donc pas à ce que je détaille les différentes étapes de l’installation, puisque çà a déjà été abordé dans les différents chapites associés. Je vous renvoie donc vers les différentes sections pour plus d’information.

Chap 1. Prise en main du RPi
—————————————–

$ df -h

$ sudo umount /dev/sdb1

$ sudo apt install dcfldd

$ sudo dcfldd if=20XX-YY-ZZ-raspbian-jessie-lite.img of=/dev/sdb bs=1M
$sync

$ sudo cat >  /etc/network/interfaces.d/eth0 << eof > auto eth0
>
> iface eth0 inet static
>     address 172.16.1.16
>      netmask 255.255.255.0
>      gateway 172.16.1.1
> eof

# ifdown eth0

# ifup eth0

# vi /etc/resolv.conf
# Generated by resolvconf
nameserver 8.8.8.8
nameserver 8.8.4.4

# chattr +i /etc/resolv.conf 


$ sudo apt update
$ sudo apt upgrade

$ sudo apt install vim

$ sudo raspi-config 

Un petit plus,

pi@raspberrypi:~ $ sudo hostname nouveau-nom
pi@nouveau-nom:~ $ sudo vim /etc/hosts
!--sortie tronquée--!
127.0.1.1	nouveau-nom

Faite une copie de sauvegarde du système installé sur la carte SD vers un autre support (disque dur local par exemple):

$ sudo umount /dev/sdb1
$ sudo umount /dev/sdb2

mon@ordi$ cd ~/Backup

$ sudo dcfldd if=/dev/sdb of=sd.img bs=4M

Chap 3. Sécuriser votre RPi
—————————————–

mon@ordi$ ssh pi@10.1.2.3

$ sudo adduser USERNAME
$ sudo adduser USERNAME sudo

$ groups pi
pi : pi adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio
$ groups USERNAME
USERNAME : USERNAME sudo

$ sudo usermod -a -G adm,dialout,cdrom,audio,video,plugdev,games,users,input,netdev,spi,i2c,gpio USERNAME

mon@ordi$ ssh USERNAME@10.1.2.3

sudo deluser --remove-home pi

Je n’ai pas réussi à supprimer l’utilisateur pi du premier coup, car la commande renvoie l’erreur que cet utilisateur a un process actif (bash). J’ai du redémarrer le RPi et relancer la même commande. Une autre alternative serait d’utiliser la commande ci-dessous:

$ sudo userdel -f pi

$ sudo passwd -dl root

$ sudo vim /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
$ sudo service ssh restart

*Connection SSH côté client
—————————————

mon@ordi$ sudo apt-get install openssh-client
mon@ordi$ ssh-keygen -t rsa

N’ommetez pas la passphrase!!!

Les clés générées devraient se trouver dans le répertoire ~/.ssh:
– clé privée: id_rsa (vous devez ne jamais fournir cette clé à personne)
– clé publique: id_rsa.pub

mon@ordi$ ssh-copy-id -i ~/.ssh/id_rsa.pub USERNAME@10.1.2.3

*Connection SSH côté server
—————————————

USERNAME@raspberrypi$ sudo apt-get install openssh-server

Vérifier et modifier les permissions pour les fichiers et dossiers si nécessaire.

drwx------ .ssh
-rw------- .ssh/authorized_keys


$ sudo vim /etc/ssh/sshd_config
PasswordAuthentication no

$ sudo service ssh restart

*Parefeux
—————————————

$ sudo vim /etc/iptables.firewall.rules
*filter

# Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT

# Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow all outbound traffic - you can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allow RDP connections from anywhere (uncomment if rdp connection is needed)
# -A INPUT -p tcp --dport 3389 -j ACCEPT

# Allow SSH connections
# The -dport number should be the same port number you set in sshd_config
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

# Allow ping
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Drop all other inbound - default deny unless explicitly allowed policy
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT
$ sudo iptables-restore < /etc/iptables.firewall.rules
$ sudo iptables -L

sudo vim /etc/network/if-pre-up.d/firewall
#!/bin/sh
/sbin/iptables-restore < /etc/iptables.firewall.rules

$ sudo chmod +x /etc/network/if-pre-up.d/firewall

$ sudo apt install fail2ban

Chap 2. Installation de OwnCloud sur un Raspberry Pi
—————————————–

$ mkdir /home/USERNAME/www-dev
$ cd /home/USERNAME/www-dev


$ sudo wget http://download.owncloud.org/community/owncloud-9.1.3.tar.bz2
$ sudo wget http://download.owncloud.org/community/owncloud-9.1.3.tar.bz2.md5
$ md5sum -c owncloud-9.1.3.tar.bz2.md5 < owncloud-9.1.3.tar.bz2
owncloud-9.1.3.tar.bz2: OK

$ sudo tar -xvf owncloud-9.1.3.tar.bz2

$ sudo chown -R www-data:www-data /home/USERNAME/www-dev

*Apache
—————————————

$ sudo vim /etc/apache2/sites-available/owncloud.conf
Alias /owncloud "/home/USERNAME/www-dev/owncloud/"
<Directory /home/USERNAME/www-dev/owncloud/>
 Options +FollowSymlinks
 AllowOverride All

 <IfModule mod_dav.c>
 Dav off
 </IfModule>

 SetEnv HOME /home/USERNAME/www-dev/owncloud
 SetEnv HTTP_HOME /home/USERNAME/www-dev/owncloud

</Directory>


Lier symboliquement /etc/apache2/sites-enable/owncloud.conf à /etc/apache2/sites-avaibled/owncloud.conf:
$ sudo a2ensite owncloud.conf

Remplacer a2ensite par a2dissite pour supprimer le lien symbolique.

$ sudo a2enmod rewrite
$ sudo a2enmod headers

$ sudo service apache2 restart
$ sudo systemctl daemon-reload

$ sudo a2enmod ssl
$ sudo a2ensite default-ssl
$ sudo service apache2 reload

$ sudo cp /etc/php5/apache2/php.ini /etc/php5/apache2/php.ini.bak
$ sudo vim /etc/php5/apache2/php.ini
upload_max_filesize = 2G
post_max_size = 2G

$ sudo service apache2 restart

 

*MySQL/MariaDB
—————————————

$ sudo mysql_secure_installation
Enter current pasword for root, #taper le mot de passe root de MariaDB, qui devrait être le même que celui lors de l'installation du service
Change root password, #taper “n” pour NON
Remove anonymous users, #taper “y” pour OUI
Disallow root login remotely, #taper “y” pour OUI
Remove test database and access to it, #taper “y” pour OUI
Reload privilege tables no, #taper “y” pour OUI

$ sudo mysql -u root -p
Enter password: #taper le mot de passe root de MariaDB

MariaDB [(none)]> CREATE USER 'ownclouduser'@'localhost' IDENTIFIED BY 'password';
MariaDB [(none)]> CREATE DATABASE IF NOT EXISTS owncloudDB;
MariaDB [(none)]> GRANT ALL PRIVILEGES ON owncloudDB.* TO 'ownclouduser'@'localhost' IDENTIFIED BY 'password';
MariaDB [(none)]> quit

 

Si vous rencontrez un message du type:

Error 403: Forbidden
You don’t have permission to access/owncloud/ on this server

Il suffit d’ajouter dans le fichier de configuration de apache2 les lignes ci-dessous. Pour rappel, ce n’est pas nécessaire de le faire avec la version 8 de Owncloud.

$ sudo vim /etc/apache2/apache2.conf

<Directory /home/USERNAME/www-dev/>
 Options Indexes FollowSymLinks
 AllowOverride All
 Require all granted
</Directory>

Chap 5. Connection en SSH
—————————————–

*SSH serveur
---------------------------------------

raspi$ sudo vim /etc/ssh/ssh_config
ClientAliveInterval 60
$ sudo service sshd restart

*SSH client
---------------------------------------

monOrdi$ vim ~/.ssh/config
Host *
ServerAliveInterval 60

Modification/mise-à-jour de la passephrase:

monOrdi$ cd ~/.ssh/

monOrdi:~/.ssh $ ls 
id_rsa id_rsa.pub 
monOrdi:~/.ssh $ ssh-keygen -f id_rsa -p

Chap 4. Accès au serveur Web Owncloud à partir
—————————————–

Je vous propose de revoir ce chapitre pour les détails du comment pointer votre adresse IP publique à votre nom de domaine.

$ sudo cp  /etc/apache2/apache2.conf  /etc/apache2/apache2.conf.bak
$ sudo vim /etc/apache2/apache2.conf

Ajouter les deux lignes a la fin de la page

ServerSignature Off
ServerTokens Prod

$ sudo service apache2 restart

$ sudo vim ~/www-dev/owncloud/config/config.php
'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => '10.1.2.3',
    2 => 'Mon.Adresse.IP.Publique',
    3 => '.netlib.re',
    4 => '.nsupdate.info',
  ),

$ sudo service apache2 restart

Voici le contenu de mon fichier /etc/apache2/site-enabled/owncloud.conf
=====================================================
Alias /owncloud "/home/USERNAME/www-dev/owncloud"

 <VirtualHost *:80>
 ServerName MaPage.netlib.re
 Redirect permanent / https://MaPage.netlib.re/
</VirtualHost>

<VirtualHost *:80>
 ServerName MaPage.nsupdate.info
 Redirect permanent / https://MaPage.nsupdate.info/
</VirtualHost>

# Web server configuration

<VirtualHost *:443>
 ServerName MaPage.netlib.re/
 ServerAlias MaPage.nsupdate.info/

 # SSL configuration
 #SSLEngine on

 # Restrict/deny/allow access to certain directories

 <Directory /home/USERNAME/www-dev/owncloud/>
 Options +FollowSymlinks
 AllowOverride All

 <IfModule mod_dav.c>
 Dav off
 </IfModule>

 SetEnv HOME /home/USERNAME/www-dev/owncloud
 SetEnv HTTP_HOME /home/USERNAME/www-dev/owncloud
 </Directory>

 <Directory "/home/USERNAME/www-dev/owncloud/data/">
 # just in case if .htaccess gets disabled
 Require all denied
 </Directory>

</VirtualHost>



# modern configuration, tweak to your needs
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite !--Sortie Tronquee--!
SSLHonorCipherOrder     on
SSLCompression          off

# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/var/run/ocsp(128000) 

 

Ci-dessous, quelques commandes utile pour vérifier les erreurs de syntax dans /var/apache2/site-enabled/owncloud.conf

$ sudo apache2ctl configtest
$ sudo journalctl | tail


$ systemctl status apache2.service 

Pour régler les problèmes annoncés dans la page d'administration de Owncloud, il suffit d'installer php5-apcu

$ sudo apt install php5-apcu 

Puis d'ajouter la ligne ci-dessous dans ~/www-dev/USERNAME/owncloud/config/config.php

<?php
$CONFIG = array (
!--Sortie Tronquee--!
'memcache.local' => '\OC\Memcache\APCu',
);
$ sudo service apache2 restart


Chap 7. Let's Encrypt (LE)
-----------------------------------------

Le nouveau système pour l'installation de LE est beaucoup plus simple qu'auparavant.


$ mkdir ~/Letsencrypt
$ cd Letsencrypt/
~/Letsencrypt $ wget https://dl.eff.org/certbot-auto
~/Letsencrypt $ chmod a+x certbot-auto $ ./certbot-auto

Puis faites un test de verification du renouvellement automatique.

~/Letsencrypt $ certbot-auto renew --dry-run 

Créer ensuite une règle dans crontab, qui va lancer automatiquement, une demande de renouvellement du certificat une fois tous les 12 heures.

$ sudo crontab -e
  #Minute Hour Day of Month Month Day of Week Command
  #(0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)

crontab
* */12 * * * /home/matakasi/letsencrypt/certbot-auto renew --quiet --no-self-upgrade >> /var/log/apache2/letsencrypt-renew.log 2>&1

Référence:

Apache on Debian (other)

Connection SSH

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 5. Connection SSH

Qu’est ce que le SSH?

« Secure Shell (SSH) est à la fois un programme informatique et un protocole de communication sécurisé. Le protocole de connexion impose un échange de clés de chiffrement en début de connexion. Par la suite, tous les segments TCP sont authentifiés et chiffrés.
Le protocole SSH a été conçu avec l’objectif de remplacer les différents programmes rlogin, telnet, rcp, ftp et rsh. » (Wikipedia)

Pour faire simple, il y a deux manières pour se connecter à un serveur distant.

Un de façon non sécurité, et que l’on déconseille fortement, puisque tout le traffic passe en mode clair sur le réseau. C’est comme si vous communiquer avec votre banquier à l’autre bout de la rue, avec un mégaphone, pour lui faire part de vos possessions et biens, ainsi que leurs emplacements.

L’autre méthode serait de chiffrer tous les échanges entre votre poste et le serveur, afin que ces communications restent confidentiels à l’abris des regards indiscrets.

Pas mal d’astuces sur la façon de mieux sécuriser l’accès au serveur SSH on déjà été proposés dans les précédents chapitre, donc je ne vais pas m’étaler dessus.Ici, je vais essayer d’ajouter quelques points non vus précédement.

Gel du terminal après disconnection du SSH

Vous avez certainement noté un problème de « gel » de votre terminal, un certain temps d’inactivité, lorsque vous vous connectez en SSH à votre serveur, et que vous n’arrivez plus à prendre la main dessus! C’est tout à fait normal, puisqu’un fois la session en SSH terminée, votre machine se déconnecte du serveur, mais ne vous laisser pas reprendre la main sur la console.

Pour y remédier, vous avez une liste de méthode.

Méthode 1:

Taper deux fois la touche « ENTREE » puis successivement sur les touches « ~ » et « . », sans les guillemets.

$ man ssh
!---Tronquée---!
The supported escapes (assuming the default ‘~’) are:
~.      Disconnect.
!---Tronquée---!

Méthode 2:

Si vous pensez que cette solution n’est pas pratique, vous pouvez toujours ajouter une ligne avec la commande « ~. », sans les guillemets bien sûr, dans le fichier .ssh/config de votre RPi.

raspi$ vim ~/.ssh/config
~.
raspi$ sudo service ssh restart

Méthode 3:

Une solution des plus classique, serait d’éditer l’un des fichiers de configuration du serveur ou de votre poste de travail. Il n’est pas nécessaire de le faire sur les deux à la fois.

SSH serveur

raspi$ sudo vim /etc/ssh/ssh_config
ClientAliveInterval 60
raspi$ sudo service sshd restart

N’oublier pas de redémarrer le service correspondant à chaque modification d’un fichier de configuration sur un serveur.

SSH client

Ajouter les deux lignes ci-dessous dans le fichier dans la configuration locale de votre ssh.

monOrdi$ vim ~/.ssh/config
Host *
ServerAliveInterval 60

L’option ServerAliveInterval va garder la connection active même si l’utilisateur est inactif. Et l’option ClientAliveInterval va tout de même envoyer des paquets vides vers le serveur toutes les 60 secondes, pour garder la connection active.

Méthode 4:

Sur le même principe qu’à la méthode 3, vous pouvez ajouter comme argument ServerAliveInterval, lorsque vous vous connectez en SSH.

monOrdi$ ssh -o ServerAliveInterval=60 user@example.com

Méthode 5:

Configurer PUTTY, avec une valeur de keepalive interval:

monOrdi$ sudo apt-get install putty

037

 

Création d’une Banière personnalisée

Afficher un message d’acceuil (Message du jour ou MOTD) lors de la connection en SSH, est une très bonne idée. Une banière peut servir à afficher un message d’avertissement, etc., celà dépend de vos besoins.
Le message d’information affiché par défaut, lors de la connection sur notre serveur RPi nous donne les informations d’utilisation du logiciel, ainsi que les informations sur la dernière connection réussie sur le serveur.

018

Pour donner une touche plus personnelle à votre banière, rendez-vous dans le fichier /etc/motd et apportez-y toutes les modifications nécessaires.

Si comme moi, vous êtes nostalgique du logo de tux, alors récupérer le logo sur github. Copier  ensuite avec un outil graphique en mode root (gvim, gksudo gedit, etc.), les lignes situées entre BEGIN_LOGO et END_LOGO.
Mais avant tout, garder tout de même une copie de l’ancien fichier motd.

raspi$ sudo mv  /etc/motd /etc/motd_old

Il va de soit que, pour se connecter en mode graphique, il nous faut un visionneur de bureau distant, Remmina par exemple, et qu’il faut aussi ouvrir le port 3389 du parefeux de votre serveur RPi si ce n’est pas le cas.

raspi$ sudo gvim /etc/motd

Et voici le résultat avec le choix de « classic.log ».

019

Customisation du MOTD

Pour un tunning un peu plus poussé de votre page, voici deux liens qui pourraient vous être utile: Customize your MOTD – LINUX,et Custom MOTD – Message of the Day.

Mettre à jour de la passephrase

Dans le cas où vous avez créé une passphrase lors de la création de clés pour une connection sécurisée entre votre poste et le serveur RPi, si comme moi vous avez utilisé un mot de passe simple pour faire des tests, il est donc temps de mettre un mot-de-passe un peu plus sûr.
Pour ce faire, à partir de l’ordinateur sur lequel vous avez généré la clé, taper,

monOrdi$ cd ~/.ssh/

monOrdi$ ls
id_rsa id_rsa.pub
monOrdi$ ssh-keygen -f id_rsa -p

A lire

Je vous recommande aussi de lire les articles suivants, si vous souhaitez approfondir vos connaissances sur le SSH:

Secure Secure Shell
Awesome SSH
The ultimate ssh tips & tricks

Sources et Réferences

SSH – ubuntu-fr
Banner Files
OpenSSH Change a Passphrase With ssh-keygen command
Connecting to a server using SSH on Linux or Mac OS

Sécuriser votre RPi

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web server à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 3. Sécuriser votre RPi

Pour sécuriser le RPi, il nous faut:

1. Créer un utilisateur autre que Pi
2. Créer une connection sécurisée entre votre ordinateur et le RPi
3. Désactiver l’authentification SSH par mot de passe ainsi que la connection en tant que Root
4. Créer des règles de parefeux
5. Installer Fail2ban

Comme toujours, lisez l’article jusqu’au bout avant d’effectuer des modifications sur votre(vos) appareil(s).

I. Création d’un nouvel utilisateur Pi

Vous l’avez surement remarqué que le système d’exploitation Raspbian, a deux utilisateurs par défaut: root et pi. Pour plus de sécurité, mieux vaut désactiver ces deux comptes, et d’en créer un qui aura les mêmes permissions que root en utilisant la commande « sudo ».

Création du nouvel utilisateur

Méthode 1:

Lancer une connection ssh avec l’utilisateur pi, le temps d’activer temporairement le compte root puisque ce dernier est inactif par défaut.

Le format pour se connecter en ssh à partir d’un terminal sous linux est de la forme « ssh pi@ ».

mon@ordi$ ssh pi@10.1.2.3

Puis taper la commande ci-dessous et entrer deux fois le mot de passe pour l’utilisateur root.

pi@raspberrypi:~$ sudo passwd
Enter new UNIX password: 
Retype new UNIX password:
pi@raspberrypi:~$ exit

Après avoir fermée la connection ssh, relancez-en une nouvelle en vous connectant cette fois-ci avec l’utilisateur root.

mon@ordi$ ssh root@10.1.2.3

La commande suivante permet de renommer l’utilisateur pi  (option -l) par le nom d’utilisateur de votre choix. Ici; j’ai décidé d’appeler mon utilisateur « USERNAME », puis créer un nouvel espace /home (option -d) et d’y placer le contenu de l’ancien /home (option -m).

root@raspberrypi:~# su -
root@raspberrypi:~# usermod -l USERNAME -d /home/USERNAME -m pi 
root@raspberrypi:~# groups USERNAME 
USERNAME : pi adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio root@raspberrypi:~# sudo groupmod -n USERNAME pi

La commande groupmod permet de remplacer le nom du groupe initialement associé à USERNAME, qui est « pi », par USERNAME. Pour rappel, généralement sous linux, le nom d’utilisateur et le nom du groupe sont identique.

root@raspberrypi:~# groups USERNAME
USERNAME : USERNAME adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio

La commande utilisée avec « usermod », peut se décomposer en deux étapes:

1. Renommer pi par USERNAME

root@raspberrypi:~# usermod -l USERNAME pi

2. Supprimer le /home/pi après avoir déplacé son contenu dans /home/USERNAME (option -d -m)

pi@raspberrypi:~$ usermod -d /home/USERNAME -m pi

Ci-dessous les quelques messages d’erreur que j’ai rencontré, mais je ne vais pas trop tarder dessus.

root@raspberrypi:~# usermod -l USERNAME -d /home/USERNAME -m pi
bash: usermod: command not found

Lancer la commande « su – » pour se placer dans le même environnement que root.

Ensuite, tuer le process utilisé par l’utilisateur PI lors de sa connection en mode GUI, sinon vous risquez d’avoir une erreur du type:

root@raspberrypi:~# su -
root@raspberrypi:~# usermod -l USERNAME -d /home/USERNAME -m pi
usermod: user pi is currently used by process 1234
root@raspberrypi:~# ps -lp 1234
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
4 S  1000  4146  4141  0  80   0 - 12556 poll_s ?        00:00:00 x-session-manag
root@raspberrypi:~# kill 4146


Méthode 2:

Cette deuxième méthode demande un peu plus d’étapes à suivre, pour arriver aux mêmes fins que précédement. Cependant, il n’est pas nécessaire d’activer le compte root pour l’ajout et la suppression d’utilisateurs. De ce fait, vous pouvez vous connecter directement en ssh avec l’utilisateur pi.

mon@ordi$ ssh pi@10.1.2.3

1. Création d’un nouvel utilisateur

$ sudo adduser USERNAME
$ sudo adduser USERNAME sudo

Vérifier que USERNAME fait bien du groupe « sudo ».

$ groups USERNAME
USERNAME : USERNAME adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio

Fermer la session pour l’ouvrir de nouveau, en vous connectant cette fois-ci avec le nouvel utilisateur .

mon@ordi$ ssh USERNAME@10.1.2.3

Pour information, le groupe SUDO n’a pas de “pouvoirs” (permissions) particuliers. C’est un groupe comme un autre. Par contre, il est spécifié dans /etc/sudoers, que tous les membres de ce groupe peuvent avoir les mêmes permissions que root lorsque la commande sudo est évoquée.
Pour vérifier cette information, taper visudo dans une console.

Nano étant le mode d’édition utilisé par défaut, si vous préférez un éditeur, lancer la commande update-alternatives pour faire votre choix.

sudo update-alternatives --config editor

Mon choix se limite à Vim, et donc je passe par une commande plus directe.

sudo update-alternatives --set editor /usr/bin/vim.tiny

Lancer maintenant visudo:

sudo visudo

Je tiens à préciser qu’il est fortement déconseillé de modifier directement le contenu de /etc/sudoers, sans passer par la commande visudo.

La ligne qui nous intéresse:

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

Je vous renvoie sur cette page pour plus d’information concernant cette ligne.
2. Vérification

Vérifier que les utilisateurs USERNAME et pi font parti des mêmes groupes avant de supprimer définitivement ce deuxième.

$ groups pi
$ groups USERNAME

S’il manque des groupes au nouvel utilisateur, n’hésitez pas à en rajouter avec la commande:

$ sudo usermod -a -G  USERNAME

3. Suppression de l’utilisateur Pi

N’oubliez pas que parmis les choix possible de ce que vous pouvez faire avec cet utilisateur pi. Le mien est de le supprimer définitivement ainsi que de le dossier home associé.

sudo deluser --remove-home USERNAME

Pour supprimer tous les fichiers ayant appartenu à cet utilisateur (je vous déconseille de le faire à moins que vous sachiez exactement ce que vous faites),

sudo deluser --remove-all-files USERNAME

4. Redémarrer le Raspi

Et voilà. Il nous a fallu quatre étapes, pour faire plus ou moins la même chose qu’avec la méthode 1.

Avant de clôturer ce chapitre, je tiens à vous préciser qu’en utilisant un système debian, il est fortement conseillé d’utiliser les commandes adduser/deluser au lieu des commandes généralement trouvées sur les autres distributions linux, que je ne vais pas citer ici afin de réduire les risques de confusions.

Désactivation/activation du compte Root

Maintenant qu’avec le nouvel utilisateur, on peut utiliser sudo, vous pouvez désactiver le compte Root si ce n’est déjà fait.

Supprimer le mot de passe du compte root (option -d, –delete), puis le vérouiller ensuite avec l’option -l (–lock).

$ sudo passwd -dl root
passwd: password expiry information changed.

Verification:

$ su -
Password:
su: Authentication failure

Pour lancer un shell en mode root, utiliser plutôt l’option -s  avec sudo (similaire à “sudo su”) au lieu de l’option -i (similaire à sudo su -). Le premier garde les informations actuel du shell, par contre la deuxième option vous envoie dans l’environement du root. Cette deuxième option est à déconseiller puisque vous allez perdre les bénéfices de sécurité offerts par sudo.

sudo -s

Si, pour une raison quelconque, vous avez besoin d’activer l’utilisateur root, l’option -u (–unlock) fera l’affaire.

$ sudo passwd -u root

Pour donner un mot de passe à l’utilisateur root,

$ sudo passwd root

II. Connection sécurisée

Je vous recommande vivement de lire l’article SSH Tutorial for Linux. Pour plus d’information sur le SSH et sur ce qu’on va faire par la suite, je vous renvoie sur le site officiel de Debian, ainsi que de lire les bonnes pratiques pour l’utilisation de SSH.

Pour créer une connection de type sécurisée, entre votre machine et le RPi, nous allons utiliser le système d’authentification SSH par clé plutôt que par mot de passe. Pour ce faire, générer une paire de clé (une privée, et une autre publique) à partir du poste qui va se connecter en ssh au RPi. Puis, envoyer une copie de la clé publique sur notre serveur RPi. Garder ensuite précieusement et loin de tout regards indiscrets, votre clé privée.

La méthode d’authentification par paire de clés a pour avantage de limiter les attaques par force brute de votre mot de passe, pour l’authentification au RPi.

Côté client

Sur votre ordinateur, vérifier que le paquet openssh-client est bien installé. Si ce n’est pas le cas, il faut le faire.

mon@ordi$ dpkg -l | grep ssh
mon@ordi$ sudo apt-get install openssh-client

Générer une paire de clés avec l’utilitaire SSH keygen.

mon@ordi$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/matakasi/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

N’ommetez pas la passphrase, qui est une forme de sécurité supplémentaire. Si quelqu’un réussit à s’approprier vos clés, il lui faut toujours entrer cette passphrase pour pouvoir se connecter à votre Serveur.

Pour bien choisir son mot de passe, je vous conseille de lire cet article.

Les clés générées devraient se trouver dans le répertoire ~/.ssh:
– clé privée: id_rsa (vous devez ne jamais fournir cette clé à personne)
– clé publique: id_rsa.pub.

Copier la clé publique sur l’hôte distant (RPi) avec la commande ssh-copy-id.

mon@ordi$ ssh-copy-id -i ~/.ssh/id_rsa.pub USERNAME@10.1.2.3

Le fichier .ssh/authorized_keys sera créé automatiquement suite à cette commande. Pour voir son contenu,

mon@ordi$ ssh USERNAME@10.1.2.3
USERNAME@raspberrypi$ cat ~/.ssh/authorized_keys

Le fichier /home/.ssh/authorized_keys est le fichier contenant les clés publiques permettant à un utilisateur de s’authentifier à l’aide de sa clé privée.

Côté Serveur

Vérifier que openssh-server est déjà installé ou non.

USERNAME@raspberrypi$ aptitude search ssh-server

Si ce n’est pas le cas,

USERNAME@raspberrypi$ sudo apt-get install openssh-server

Modifier ensuite les permissions du dossier /home/.ssh si vous n’avez pas les mêmes informations que ci-dessous.

USERNAME@raspberrypi$ ls -al | grep .ssh
drwx------ 2 USERNAME USERNAME 4096 Feb 23 00:14 .ssh

USERNAME@raspberrypi$ ls -al .ssh/authorized_keys
-rw------- 1 USERNAME USERNAME 397 Feb 23 00:14 .ssh/authorized_keys

Vous ne devriez pas avoir à modifier quoi que ce soit concernant les permissions, mais si vous n’avez pas les mêmes permissions que moi, vous pouvez toujours mettre à jour vos permissions avec la commande chmod.

sudo chmod 700 .ssh
sudo chmod 600 .ssh/authorized_keys

III. Désactivation du mot de passe pour l’autentification SSH et du compte Root

sudo vim /etc/ssh/sshd_config

Rechercher les informations PasswordAuthentication puis PermitRootLogin, et de remplacer leurs valeurs par « no ».

#Désactiver l’utilisation du mot de passe pour l’authentification
PasswordAuthentication no

#Désactiver l’utilisation du compte root
PermitRootLogin no

Relancer ensuite le serveur SSH.

sudo service ssh restart

IV. Creating a Firewall

Maintenant, il nous faut ajuster les paramètres du parefeux pour limiter/bloquer certain traffics vers le RPi.

Vérifier quelles sont les règles actuelles de votre parefeux sur le RPi

sudo iptables -L

Par défaut, vous ne devriez pas avoir de règles du tout. Tout traffic devrait être autorisé,

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

 

Créer un fichier pour y placer les règles du parefeux

sudo vim /etc/iptables.firewall.rules

Copier les règles ci-dessous dans /etc/iptables.firewall.rules.

*filter

# Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT

# Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow all outbound traffic - you can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allow RDP connections from anywhere (uncomment if rdp connection is needed)
# -A INPUT -p tcp --dport 3389 -j ACCEPT

# Allow SSH connections
# The -dport number should be the same port number you set in sshd_config
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

# Allow ping
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Drop all other inbound - default deny unless explicitly allowed policy
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT

Vous pouvez supprimer le commentaire au niveau du RDP (3389), si vous avez besoin d’accéder à l’interface graphique du RPi. Les règles appliquées ci-dessus autorise les traffics en HTTP (80), HTTPS (443), SSH (22), ainsi que les ping.

 

Activer les nouvelles règles du parefeux

sudo iptables-restore < /etc/iptables.firewall.rules

Vérifier de nouveau que les nouvelles règles sont actifs.

sudo iptables -L

Vous devriez maintenant avoir quelque chose de similaire.

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             loopback/8           reject-with icmp-port-unreachable
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:3389
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
LOG        all  --  anywhere             anywhere             limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: "
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere 

 

Activation automatique des règles du parefeux

Vous devriez vous assurer que ces règles sont toujours activées à chaque fois que vous redémarrer le RPi. Pour ce faire, nous allons créer un script pour automatiser la tâche.

sudo vim /etc/network/if-pre-up.d/firewall

Copier les lignes ci-dessous:

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

Puis modifier les permissions de ce fichier.

sudo chmod +x /etc/network/if-pre-up.d/firewall

V. Installation et Configuration de Fail2Ban

Fail2Ban est un très bon outil pour détecter les tentatives de connection sur vos serveurs. Une fois une intrusion détectée, après un nombre défini de tentative de connection, Fail2Ban va créer automatiquement une règle dans iptable pour bannir l’adresse IP de l’intrus (blacklister).

Fail2Ban se trouve dans les dépots officiels de Debian. Pour l’installer,

sudo apt-get install fail2ban

Une fois l’installation terminée, il n’y a rien de plus à faire, à part vérifier dans les logs dans /var/log/fail2ban.log les informations enregistrées par l’application.
Pour information, Fail2Ban surveille uniquement les traffics pour le protocol SSH par défaut. Mais vous pouvez le configurer afin de superviser les tentatives de connections à votre serveur pour d’autres protocols tel HTTP, RDP, SMTP, etc.

 

Notes:

How do I change pi’s username?
How can I add a new user as sudoer using the command line?
How to properly configure sudoers file, on debian wheezy?
How to add self to sudoers list?
Allowing other users to run sudo
Add a User to a Group (or Second Group) on Linux
How to change owner and group of a file in Linux
Raspberry Pi Home Server: Part 4, Web Administration
A Complete Guide to Usage of ‘usermod’ command – 15 Practical Examples with Screenshots
What do the “ALL”s in the line “ %admin ALL=(ALL) ALL ” in Ubuntu’s /etc/sudoers file stand for?
Effect of (ALL:ALL) in sudoers?
Sudo and Sudoers Configuration
Securing Your Server
Users and Groups Administration in Linux

Cisco: ACL

Le but ici est de creer des filtres au niveau des ports des switchs.

Fichier a telecharger: acl_clean.pkt
Logiciel: packet tracer

Consignes:

  • VTP, désactiver STP sur les interfaces clientes, et désactiver DTP
  • Empêcher les membres de vlan vert de pinguer vlan bleu, mais vlan bleu peut pinger vlan vert.
  • Empêcher le HTTP pour les membres de vlan vert, mais autoriser le HTTPS vers le vlan bleu
  • Empêcher le telnet pour les membres de vlan bleu & vert
  • Autoriser SSH à tout le monde, mais autoriser la connection SSH sur R0 uniquement pour les membres de vlan bleu

VLAN 10 = BLEU => 10.0.10.0/25
VLAN 20 = VERT => 10.0.20.0/27

VTP domaine: egilia
VTP passwod: learning

****************************************************
Correction

****************************************************

Premiere configuration sur les switchs
 » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » »
On ne le dit jamais assez, mais avant d’ajouter un nouveau switch sur un reseau, il est fortement conseille d’effacer tout ce qu’il y a dessus.

Switch#delete flash:
    Delete filename []?vlan.dat
Switch#erase startup-config
Switch# reload

Switch#configure terminal
Switch(config)#no ip domain-lookup
Switch(config)#line console 0
Switch(config-line)#logging synchronous
Switch(config-line)#no exec-timeout
<== a eviter, mais pratique lorsqu'on configure un switch

Switch0(config)#hostname Sw0

Switch1(config)#hostname Sw1

Configuration VTP
 » » » » » » » » » » » » » » » » » » »’

Sw0(config)#vtp mode server
    (config)#vtp domain egilia
    (config)#vtp password learning

Sw1(config)#vtp mode client
    (config)#vtp domain egilia
    (config)#vtp password learning

Verification:
#show vtp status

Creation des VLANs sur le serveur
 » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » »

Sw0(config)#vlan 10
    (config-vlan)#name BLEU
    (config-vlan)#vlan 20
    (config-vlan)#name VERT

Verification sur Switch0:
#show vlan brief

Configuration des liens Trunks
 » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » »

Sw0(config)#int range f0/1-2
Sw0(config-if-range)#switchport mode trunk

Sw1(config)#int f0/2
Sw1(config-if-range)#switchport mode trunk

Verification sur Switch1:
#show vlan brief

Definir les interfaces clients:
 » » » » » » » » » » » » » » » » » » » »’
Sw0(config)#int f0/10
    (config-if)#switchport mode access
    (config-if)#switchport access vlan 10
    (config-if)#int f0/20
    (config-if)#switchport mode access
    (config-if)#switchport access vlan 20

Sw1(config)#int f0/10
    (config-if)#switchport mode access
    (config-if)#switchport access vlan 10
    (config-if)#int f0/20
    (config-if)#switchport mode access
    (config-if)#switchport access vlan 20

Verification:
#show vlan brief

Configuration du routage InterVLAN
 » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » »
Routeur0(config)#hostname Router0
    (config)#no ip domain-lookup
    (config)#line console 0
    (config-line)#logg synchronous

Router0(config)#int f0/0
    (config-if)#no shutdown

Router0(config)#int f0/0.10
    (config-subif)#encapsulation dot1Q 10
    (config-subif)#ip address 10.0.10.126 255.255.255.128
    (config-subif)#int f0/0.20
    (config-subif)#encapsulation dot1Q 20
    (config-subif)#ip address 10.0.20.30 255.255.255.224

Configuration des DHCP
 » » » » » » » » » » » » » » » » » » » » » » » » »’

Router0(config)#ip dhcp pool VLAN10
    (dhcp-config)#network 10.0.10.0 255.255.255.128
    (dhcp-config)#default-router 10.0.10.126
    (dhcp-config)#dns-server 8.8.8.8
    (dhcp-config)#ip dhcp pool VLAN20
    (dhcp-config)#network 10.0.20.0 255.255.255.224
    (dhcp-config)#default-router 10.0.20.30
    (dhcp-config)#dns-server 8.8.8.8

Config les interfaces clients – se proteger contre BPDU en desactivant STP sur interfaces clients
 » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » »’

Sw0(config)#spanning-tree portfast default
    (config)#int range f0/10 , f0/20
    (config-if-range)#spanning-tree bpduguard enable
    (config-if-range)#spanning-tree guard root

Sw1(config)#spanning-tree portfast default
    (config)#int range f0/10 , f0/20
    (config-if-range)#spanning-tree bpduguard enable
    (config-if-range)#spanning-tree guard root

Securite sur le VLAN – mise en place de la non negociate – pour supprimer les DTP(Dynamic Trunking Port):
 » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » »’

Sw0#int range f0/10, f0/20
    #switchport nonegotiate
    #switchport port-security maximum 1
    #switchport port-security violation shutdown
    #switchport port-security mac-address sticky

Sw1#int range f0/10,f0/20
    #switchport nonegotiate
    #switchport port-security maximum 1
    #switchport port-security violation shutdown
    #switchport port-security mac-address sticky

Correction ACL
 » » » » » » » » » » » » » » » »’

==============================
/debut Brouillon pour preparer les ACL
==============================

On va chercher à analyser le filtrage demandé:
« « « « « « « « « « « « « « « « « « « « « « « 
Le but est de transformer chaque question en ACE, ensuite de mettre les ACE dans l’ordre de manière à ce qu’elles ne puissent pas se neutraliser, et reste à faire une optimisation pour avoir le moins d’entrée possible.

1/ Empêcher les membres de vlan vert de pinguer vlan bleu, mais vlan bleu peut pinger vlan vert

   deny icmp VERT BLEU echo
   permit icmp VERT BLEU echo-reply

 
2/ Empêcher le HTTP pour les membres de vlan vert, mais autoriser le HTTPS vers le vlan bleu

   deny tcp VERT host SERVER0 eq 80
   permit tcp VERT host SERVER0 eq 443

3/ Empêcher le telnet pour les membres de vlan bleu & vert   

  deny tcp VERT any eq 23
  deny tcp BLEU any eq 23

4/ Autoriser SSH à tout le monde, mais autoriser la connection SSH sur R0 uniquement pour les membres de vlan bleu

   permit tcp VERT any eq 22
   permit tcp BLEU any eq 22

   permit tcp BLEU host 10.0.10.1 eq 22

Brouillon – Application de l’ACL
 » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » » »’
   F0/0.10 IN
   deny tcp BLEU any eq 23
   permit ip any any
  
   F0/0.20 IN
    permit icmp VERT BLEU echo-reply
    permit tcp VERT host SERVER0 eq 443
    permit tcp VERT any eq 22
    (deny ip any any)

   
=> line vty
 access-class noSSHVERT

 ip access-list standard noSSHVERT
    deny 10.0.20.0 0.0.0.31
   
   
 permit icmp 10.0.20.0 0.0.0.31 10.0.10.0 0.0.0.127 echo-reply
    permit tcp 10.0.20.0 0.0.0.31 host 10.0.10.100 eq 443
    permit tcp 10.0.20.0 0.0.0.31 any eq 22

==============================
/fin Brouillon pour preparer les ACL
==============================

Creation d’ACL nomme
—————————————

Router0(config)#ip access-list standard noSSHVERT
    (config-std-nacl)#permit 10.0.10.0 0.0.0.127
    (config-std-nacl)#exit
Router0(config)#ip access-list extended noTELNETbleu
    (config-ext-nacl)#deny tcp 10.0.10.0 0.0.0.127 any eq telnet
    (config-ext-nacl)#permit ip any any
    (config-ext-nacl)#exit
Router0(config)#ip access-list extended VERTacl
    (config-ext-nacl)#permit icmp 10.0.20.0 0.0.0.31 10.0.10.0 0.0.0.127 echo-reply
    (config-ext-nacl)#permit tcp 10.0.20.0 0.0.0.31 host 10.0.10.100 eq 443
    (config-ext-nacl)#permit tcp 10.0.20.0 0.0.0.31 any eq 22
    (config-ext-nacl)#deny ip any any

Application de l’ACL
———————————-

Router0(config)#int f0/0.10
    (config-subif)#ip access-group noTELNETbleu in
Router0(config-subif)#int f0/0.20
    (config-subif)#ip access-group VERTacl in

 Fichier contenant la correction a telecharger: acl_correction.pkt