Auteur/autrice : Pierre

Eclipse et le plugin git (egit) pour Linux et Windows

Dans les articles précédents je vous avais parlé de git et afin de le securiser avec gitolite.

Installation du plugin EGIT

Si on désire utiliser git avec eclipse, il nous faut le plugin EGIT présent ici : Site d’information sur egit

Si on regarde sur ce site, on peut avoir le répertoire afin de télécharger egit via Eclipse :
On ajoute le lien puis on sélectionne EGIT (http://download.eclipse.org/egit/updates).


On clique sur suivant et on lance l’installation.
Une fois l’installation terminée, on rédémarre et nous voila avec le plugin EGIT.

Configuration du plugin

La configuration du fichier pour ssh est utile uniquement si vous souhaitez avec votre clé privée (notamment pour utiliser avec gitolite)

Pour rappel des articles précédents, j’ai configuré dans mon fichier de configuration ssh (~/.ssh/config) de la manière suivante :

host gitolite
    user git 
    hostname monServeur
    port 22
    identityfile ~/.ssh/pierre

Pour Windows, c’est le même principe dans mon cas : C:\Users\pierre\.ssh (pierre étant mon utilisateur)

De plus, On peut aussi configurer le fichier .gitconfig (windows : C:\Users\pierre\.gitconfig, linux : ~/.gitconfig) :

$ cat ~/.gitconfig
[color]
        diff = auto
        status = auto
        branch = auto
[user]
        name = Pierre
        email = pierre@oversimple.fr

Plus d’informations sur les configurations ssh et gitconfig dans la catégorie git ici

Importer un projet

Importons un projet GIT avec notre plugin EGIT.

Pour cela File > Import > Projects from Git :

On sélectionne URI car notre répertoire est distant.

Explication de la configuration :
URI : On ne saisit rien par défaut.
Host : On saisit gitolite car cela fait référence à ma configuration du .ssh/config
Repository path : le nom de notre répertoire sur git.
Protocol SSH.

De cette manière la ligne est automatiquement créée pour le champ URI.

Après on choisit la branche sur lequel on doit travailler. Dans mon cas je n’ai qu’une branche Master. Je clique sur Next, afin de configurer mon répertoire Local.

Maintenant au travail…

De cette manière, nous avons les outils nécessaires pour travailler en équipe lorsque l’on fait un clic droit sur notre projet où un fichier de notre projet on obtient Team.

Voici les informations disponibles :

It’s oversimple isn’t it?

Raspberry Pi : Installation Archlinux sur carte SD 16GO


Installation d’Archlinux sur Carte SD 16 Go pour un Raspberry Pi Modèle B.

Télechargement de la derniere version de archlinux ARM, sur le site de Raspberry Pi : http://www.raspberrypi.org/downloads

Actuellement la dernière version est celle datant du 18 Septembre 2012 :

$ wget http://files.velocix.com/c1410/images/archlinuxarm/archlinux-hf-2012-09-18/archlinux-hf-2012-09-18.zip

On vérifie l’intégrité (toujours utile) :

$ sha1sum archlinux-hf-2012-09-18.zip
56e043f3c629f6c408759bcc157d2d635ce0b6af  archlinux-hf-2012-09-18.zip

On extrait notre archive zip :

 unzip archlinux-hf-2012-09-18.zip

On met en place notre Carte SD, pour connaitre quel périphérique est utilisé on fait un petit « dmesg »

$ dmesg
...(extrait)...
[ 6685.088186] scsi 7:0:0:0: Direct-Access     Multiple Card  Reader     1.00 PQ: 0 ANSI: 0
[ 6685.826912] sd 7:0:0:0: [sdb] 31504384 512-byte logical blocks: (16.1 GB/15.0 GiB)
[ 6685.828905] sd 7:0:0:0: [sdb] Write Protect is off
[ 6685.828911] sd 7:0:0:0: [sdb] Mode Sense: 03 00 00 00
[ 6685.830904] sd 7:0:0:0: [sdb] No Caching mode page present
[ 6685.830910] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 6685.836904] sd 7:0:0:0: [sdb] No Caching mode page present
[ 6685.836910] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 6685.838290]  sdb: sdb1 sdb2
[ 6685.843910] sd 7:0:0:0: [sdb] No Caching mode page present
[ 6685.843917] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 6685.843921] sd 7:0:0:0: [sdb] Attached SCSI removable disk

on voit que notre carte SD correspond, au device /dev/sdb

On pose notre systeme :

$ sudo dd if=archlinux-hf-2012-09-18.img of=/dev/sdb bs=1M
1886+0 records in
1886+0 records out
1977614336 bytes (2.0 GB) copied, 168.367 s, 11.7 MB/s

On place notre carte dans le raspberry, on branche écran hdmi/clavier usb OU le cable ethernet, on boot et on peut se connecter en ssh sur notre raspberry 😉 (root/root)
Pour connaître notre ip, si on a pas d’écran HDMI (ou d’apdateur HDMI, VGA/DVI) : nmap -sn 192.168.1.0/24

$ nmap 192.168.1.0/24
 
Nmap scan report for 192.168.1.16
Host is up (0.040s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
22/tcp open  ssh

On se connecte :

ssh root@192.168.1.16

Maintenant, on partitionne les 16 GO sur la Carte SD

# fdisk /dev/mmcblk0

On regarde les partitions avec la commande p :

Command (m for help): p
Disk /dev/mmcblk0: 16.1 GB, 16130244608 bytes
4 heads, 16 sectors/track, 492256 cylinders, total 31504384 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c21e5
 
        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1   *        2048      194559       96256    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          194560     3862527     1833984   83  Linux

On supprime la partition 2 afin de la refaire pour nos 16GO, il est possible si vous le désirez de partionner d’une autre manière mais cela reste le même principe

Command (m for help): d  
Partition number (1-4): 2
Partition 2 is deleted

On peut vérifier le résultat :

Command (m for help): p  
Disk /dev/mmcblk0: 16.1 GB, 16130244608 bytes
4 heads, 16 sectors/track, 492256 cylinders, total 31504384 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c21e5
 
        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1   *        2048      194559       96256    c  W95 FAT32 (LBA)

On crée une nouvelle partition avec les mêmes infos seul le last sector change.

Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): p
Partition number (1-4, default 2): 2
First sector (194560-31504383, default 194560): 
Using default value 194560
Last sector, +sectors or +size{K,M,G} (194560-31504383, default 31504383): 
Using default value 31504383
Partition 2 of type Linux and of size 15 GiB is set

On enregistre avec la commande w

Command (m for help): w
The partition table has been altered!
 
Calling ioctl() to re-read partition table.
 
WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

On redémarre.

Le travail n’est pas terminé, il faut l’appliquer pour le filesystem.

Pour cela on resize, c’est assez long.

# resize2fs /dev/mmcblk0p2 
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/mmcblk0p2 to 3913728 (4k) blocks.

Et après, c’est terminé ! On reboot notre système et voila 🙂

Après un petit redémarrage on peut faire les mises à jour, ainsi que changer le nom de la machine.

Pour les mises à jour :

# pacman -Suy

On modifie notre nom de machine.

vi /etc/hostname

Et si vous désirez installer des packages qui ne sont pas présents dans le mirror list pour ARM mais présent sur les dépôts pour x86 et x86_64 :
On récupère un package, on modifie son PKGBUILD de manière à remplacer les architectures existantes par la notre : uname -m
Et après c’est la routine : makepkg –asroot PKGBUILD et voilà
Après on installe notre archive. Dans mon cas, cela a été nécessaire lors de l’installation du package dsniff.

It’s OverSimple, isn’t it ?

Nmap, un scanner puissant !

Ah Nmap qui ne le connait pas ? Le scanner de port qui passe dans pleins de films : Matrix Reloaded, Bourne Ultimatum, Die Hard 4 et pleins d’autres. Plus d’informations ici.

Plus sérieusement, Nmap permet en plus de scanner des ports, d’identifier les services hébergés ainsi que le système d’exploitation distant.

Voici quelques commandes, cette liste est bien sûre non exhaustive, je me permettrai de rajouter les commandes qui peuvent m’être utile par la suite !

Un scan nmap « basique » :

# nmap 192.168.1.1
 
Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-12 20:07 CEST
Nmap scan report for 192.168.1.1
Host is up (0.00040s latency).
Not shown: 989 filtered ports
PORT     STATE  SERVICE
21/tcp   open   ftp
80/tcp   open   http
139/tcp  open   netbios-ssn
445/tcp  open   microsoft-ds
548/tcp  closed afp
554/tcp  open   rtsp
5000/tcp open   upnp
5001/tcp closed commplex-link
5678/tcp open   rrac
8090/tcp open   unknown
9091/tcp open   xmltec-xmlmail
MAC Address: 13:37:13:37:13:37 (La box de mon FAI)
 
Nmap done: 1 IP address (1 host up) scanned in 4.77 seconds

Utiliser le TCP Scan connu sous le nom de Scan SYN. Le paquet SYN est le premier envoyé lors d’une connexion TCP, le TCP handshake sera réinitialisé si le port est détecté comme ouvert.

# nmap -sS 192.168.1.1
 
Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-12 20:07 CEST
Nmap scan report for 192.168.1.1
Host is up (0.00037s latency).
Not shown: 989 filtered ports
PORT     STATE  SERVICE
21/tcp   open   ftp
80/tcp   open   http
139/tcp  open   netbios-ssn
445/tcp  open   microsoft-ds
548/tcp  closed afp
554/tcp  open   rtsp
5000/tcp open   upnp
5001/tcp closed commplex-link
5678/tcp open   rrac
8090/tcp open   unknown
9091/tcp open   xmltec-xmlmail
MAC Address: 13:37:13:37:13:37 (La box de mon FAI)
 
Nmap done: 1 IP address (1 host up) scanned in 5.06 seconds

Et pour voir les ports UDP ouvert :

# nmap -sU 192.168.1.1
 
Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-12 20:20 CEST
Nmap scan report for 192.168.1.17
Nmap scan report for 192.168.1.1
Host is up (0.00035s latency).
Not shown: 993 closed ports
PORT     STATE         SERVICE
53/udp   open          domain
67/udp   open|filtered dhcps
123/udp  open          ntp
137/udp  open          netbios-ns
138/udp  open|filtered netbios-dgm
1900/udp open|filtered upnp
5353/udp open          zeroconf
MAC Address: 13:37:13:37:13:37 (La box de mon FAI)
 
Nmap done: 1 IP address (1 host up) scanned in 1087.27 seconds

Scan de port

Scanner un port bien précis :

nmap -p 1337 192.168.1.1
 
Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-12 20:20 CEST
Nmap scan report for 192.168.1.1
Host is up (0.00024s latency).
PORT     STATE    SERVICE
1337/tcp filtered waste
MAC Address: 13:37:13:37:13:37 (La box de mon FAI)
 
Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

Lorsque l’on souhaite scanner des plages avec nmap, (plages de ports) :

# nmap -p 1337-7331,80 192.168.1.1
 
Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-12 20:21 CEST
Nmap scan report for 192.168.1.1
Host is up (0.00029s latency).
Not shown: 5991 filtered ports
PORT     STATE  SERVICE
80/tcp   open   http
5000/tcp open   upnp
5001/tcp closed commplex-link
5678/tcp open   rrac
6600/tcp closed mshvlm
MAC Address: 13:37:13:37:13:37 (La box de mon FAI)
 
Nmap done: 1 IP address (1 host up) scanned in 17.94 seconds

Ici on scanne la rangée de port suivante : 1337 à 7331
Ainsi que le port 80.

Avant on faisait un scan de ping ( -sP ), dans les nouvelles versions de nmap c’est  « No port scan » soit -sn.
Quand on fait cette commande avec les droits root, on scanne : ‘ICMP echo request, TCP SYN to port 443, TCP ACK to port 80, and an ICMP timestamp request by default’
Quand on fait cette commande avec les droits utilisateurs : seulement le paquet SYN est envoyé pour le port 80 et 443

No port scan :

# nmap -sn 192.168.1.1
 
Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-12 20:54 CEST
Nmap scan report for 192.168.1.1
Host is up (0.00027s latency).
MAC Address: 13:37:13:37:13:37 (La box de mon FAI)
Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds

Scan système d’exploitation

Découvrir le système d’exploitation de la machine distance :

nmap -O 192.168.1.1
 
Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-12 20:21 CEST
Nmap scan report for 192.168.1.1
Host is up (0.00030s latency).
Not shown: 989 filtered ports
PORT     STATE  SERVICE
21/tcp   open   ftp
80/tcp   open   http
139/tcp  open   netbios-ssn
445/tcp  open   microsoft-ds
548/tcp  closed afp
554/tcp  open   rtsp
5000/tcp open   upnp
5001/tcp closed commplex-link
5678/tcp open   rrac
8090/tcp open   unknown
9091/tcp open   xmltec-xmlmail
MAC Address: 13:37:13:37:13:37 (La box de mon FAI)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:kernel:2.6 cpe:/o:linux:kernel:3
OS details: Linux 2.6.38 - 3.2
Network Distance: 1 hop
 
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.91 seconds

Si celui-ci n’arrive pas à affiner les recherches, il fait une recherche agressive :

# nmap -O --osscan-guess 192.168.1.1
 
Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-12 20:22 CEST
Nmap scan report for 192.168.1.1
Host is up (0.00028s latency).
Not shown: 989 filtered ports
PORT     STATE  SERVICE
21/tcp   open   ftp
80/tcp   open   http
139/tcp  open   netbios-ssn
445/tcp  open   microsoft-ds
548/tcp  closed afp
554/tcp  open   rtsp
5000/tcp open   upnp
5001/tcp closed commplex-link
5678/tcp open   rrac
8090/tcp open   unknown
9091/tcp open   xmltec-xmlmail
MAC Address: 13:37:13:37:13:37 (La box de mon FAI)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:kernel:2.6 cpe:/o:linux:kernel:3
OS details: Linux 2.6.38 - 3.2
Network Distance: 1 hop
 
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.74 seconds

Scan exhaustif

Le scan typique de NMAP, qui comprend le scan des ports, le traceroute la détection d’OS et sa version. Et le T4 signifie que le scan doit être plus rapide

# nmap -A -T4 192.168.1.1
 
Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-12 20:23 CEST
Nmap scan report for 192.168.1.1
Host is up (0.00031s latency).
Not shown: 989 filtered ports
PORT     STATE  SERVICE           VERSION
21/tcp   open   ftp               box ftpd
80/tcp   open   http              nginx
|_http-methods: No Allow or Public header in OPTIONS response (status code 405)
| http-robots.txt: 1 disallowed entry 
|_/
|_http-title: Accueil box Server
139/tcp  open   netbios-ssn       Samba smbd 3.X (workgroup: WORKGROUP)
445/tcp  open   netbios-ssn       Samba smbd 3.X (workgroup: WORKGROUP)
548/tcp  closed afp
554/tcp  open   rtsp              box rtspd 1.2
| rtsp-methods: 
|_  DESCRIBE, OPTIONS, SETUP, TEARDOWN, PLAY, PAUSE
5000/tcp open   rtsp              RogueAmoeba Airfoil rtspd 110.63
| rtsp-methods: 
|_  ANNOUNCE, SETUP, RECORD, PAUSE, FLUSH, TEARDOWN, OPTIONS, GET_PARAMETER, SET_PARAMETER, POST, GET
5001/tcp closed commplex-link
5678/tcp open   upnp              fbxigdd 1.0 (AliceBox PM203 UPnP; UPnP 1.0)
8090/tcp open   hadoop-jobtracker Apache Hadoop
|_http-methods: No Allow or Public header in OPTIONS response (status code 302)
|_http-title: Probl\xC3\xA8me de connexion Internet
9091/tcp open   http              nginx
|_http-methods: No Allow or Public header in OPTIONS response (status code 405)
|_http-title: 403 Forbidden
MAC Address: 13:37:13:37:13:37 (La box de mon FAI)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:kernel:2.6 cpe:/o:linux:kernel:3
OS details: Linux 2.6.38 - 3.2
Network Distance: 1 hop
Service Info: OSs: Mac OS X, Linux 2.6; Devices: media device, WAP; CPE: cpe:/o:apple:mac_os_x, cpe:/o:linux:kernel:2.6
 
Host script results:
| smb-security-mode: 
|   Account that was used for smb scripts: guest
|   User-level authentication
|   SMB Security: Challenge/response passwords supported
|_  Message signing disabled (dangerous, but default)
|_nbstat: NetBIOS name: box, NetBIOS user: , NetBIOS MAC: 
|_smbv2-enabled: Server doesn't support SMBv2 protocol
| smb-os-discovery: 
|   OS: Unix (Samba 3.0.37)
|   NetBIOS computer name: 
|   Workgroup: WORKGROUP
|_  System time: 2012-09-12 20:23:42 UTC+0
 
TRACEROUTE
HOP RTT     ADDRESS
1   0.31 ms 192.168.1.1
 
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 23.24 seconds

Nmap bonus

Scanner toujours la meme machine mais on spoof notre adresse mac.

nmap --spoof-mac Apple 192.168.1.1

Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-12 20:24 CEST
Spoofing MAC address 00:03:93:4B:A8:C4 (Apple Computer)
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.48 seconds

Sauvegarder les résultats dans un fichier :
XML :

nmap -oX output.xml 192.168.1.1

Standard :

nmap -oN output 192.168.1.1

Ce qui peut aussi être intéressant est Nmap Scripting Engine (NSE) : Le but du NSE est de fournir à Nmap une infrastructure flexible afin d’étendre ses capacités et ainsi offrir à ses utilisateurs une façon simple de créer ses propres tests personnalisés. Plus d’informations ici.

Scan avec les scripts par défaut :

# nmap -sC 192.168.1.254
 
Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-12 21:26 CEST
Nmap scan report for 192.168.1.254
Host is up (0.00035s latency).
Not shown: 989 filtered ports
PORT     STATE  SERVICE
21/tcp   open   ftp
80/tcp   open   http
| http-robots.txt: 1 disallowed entry 
|_/
|_http-methods: No Allow or Public header in OPTIONS response (status code 405)
|_http-title: Accueil box Server
139/tcp  open   netbios-ssn
445/tcp  open   microsoft-ds
548/tcp  closed afp
554/tcp  open   rtsp
| rtsp-methods: 
|_  DESCRIBE, OPTIONS, SETUP, TEARDOWN, PLAY, PAUSE
5000/tcp open   upnp
5001/tcp closed commplex-link
5678/tcp open   rrac
8090/tcp open   unknown
9091/tcp open   xmltec-xmlmail
MAC Address: 13:37:13:37:13:37 (La box de mon FAI)
 
Host script results:
|_nbstat: NetBIOS name: box, NetBIOS user: , NetBIOS MAC: 
| smb-security-mode: 
|   Account that was used for smb scripts: guest
|   User-level authentication
|   SMB Security: Challenge/response passwords supported
|_  Message signing disabled (dangerous, but default)
|_smbv2-enabled: Server doesn't support SMBv2 protocol
| smb-os-discovery: 
|   OS: Unix (Samba 3.0.37)
|   NetBIOS computer name: 
|   Workgroup: WORKGROUP
|_  System time: 2012-09-12 21:26:55 UTC+0
 
Nmap done: 1 IP address (1 host up) scanned in 12.44 seconds

Et en plus de NSE, contourner un pare-feu avec nmap : http://nmap.org/man/fr/man-bypass-firewalls-ids.html

Source :

Le site officiel : http://nmap.org/

Le man de nmap : http://nmap.org/man/fr/

Logo NMAPIt’s oversimple isn’t it?

Et si on sauvegardait notre base de données ?

Avoir un site web c’est bien, mais en faire des sauvegardes ça peut toujours être utile. L’objectif de cet article est de vous montrer comment on sauvegarde notre base de données. Le principe de cette sauvegarde est simple. Ovh éxecute un script que l’on aura stocké sur notre espace personnel. Ce script sauvegardera notre base de données et on obtiendra un fichier SQL contenant notre BDD. Ensuite, un autre script, qui se trouve sur mon serveur personnel, se connectera afin d’aller chercher cette sauvegarde. Vous allez me dire, pourquoi c’est mon serveur qui se connecte au serveur Oversimple ? Tout simplement car je considère que mon serveur est « fiable » contrairement à un serveur mutualisé d’OVH.

Script PHP sur serveur OVH.

<?php
#php doit être supérieur à 5.1

$user="login";
$password="mot de passe";
$nom_de_la_base="baseName";
$serveur_sql="le serveur";
 
#Recupération de la date du jour : JJ-MM-AAAA 
$dateArchive =  date("d-m-Y");
 
#Sauvegarde de la base -> sortie vers un fichier sql -> overSimple-DD-MM-YYYY.sql
system("mysqldump --host=$serveur_sql --user=$user --password=$password $nom_de_la_base > overSimple-$dateArchive.sql");
 
#Récupération de la date a moins 28 jours afin de viser une ancienne archive
$newDate = strtotime('-28 day', strtotime ($dateArchive) );
$newDate = date('d-m-Y', $newDate);
 
#Verification si l'archive existe, on la supprime afin de ne pas en avoir de trop
if(file_exists("overSimple-$newDate.sql")){
	unlink("overSimple-$newDate.sql");
}
 
?>

Script Shell sur mon serveur personnel

#!/bin/sh
 
HOST='le ftp'
PORT='21'
USER='le login'
PASSWORD='un mot de passe ;)'
 
DATE=`date +%d-%m-%Y`
NAME_FILE=overSimple-$DATE.sql
 
#On va dans le repertoire de sauvegarde
cd `dirname $0`
ftp -n $HOST $PORT <<END
quote USER $USER
quote PASS $PASSWORD
cd sauvegarde/
get $NAME_FILE
quit
END
 
#On vérifie si on a télècharger le fichier.
if [ ! -f $NAME_FILE ]
then
    echo "Le fichier n'existe pas !, on le reprogramme pour dans 2 heures"
    echo sh $0 | at now + 2 hours
fi
 
exit

On plannifie l’execute sur OVH

Tous les lundis à 1h du matin. (Hébergement -> Planificateur de tâches)

On planifie sur le serveur

Pour cela rien de bien compliqué, une petite tache cron chaque lundi à 2h du matin (on a de la marge) :

$ crontab -e
00 02 * * 1 /home/overSimple/sauvegarde/sauvegarde.sh
 
On quitte (:wq) et on obtient :
crontab: installing new crontab

Et voilà, on obtient une petite sauvegarde hebdomadaire !

Installation de GITOLITE sous OpenBSD

Gitolite est un projet Open Source permettant de gérer des droits sur les dépôts Git en utilisant le principe des ACL.

Gitolite utilise des utilisateurs virtuels qui sont basés sur un unique utilisateur système. Ces utilisateurs virtuels ne possèdent pas d’accès au shell de la machine. Un git shell leur permet d’effectuer les différentes commandes.

 Pourquoi ai je installé GITOLITE ?

Tout simplement pour les différents projets d’OverSimple.  En effet, avant d’ouvrir ce site, Julien et moi avons développer un Hotspot wifi (peut être un aperçu bientôt). Nous l’avions fait sans gestionnaire de sources,  ce qui nous a posé quelques problèmes de cohésion. Après cette expérience, nous avons décidé de mettre en place un Git. La question qui s’est alors posée concernait l’emplacement de celui-ci. Sur mon serveur ? Sur un serveur commun à nous deux ? Actuellement, nous ne possédons aucun serveur en commun. J’ai donc installé Git sur ma machine personnelle. Cependant, comment faire pour que l’on puisse travailler ensemble sans que nos projets soient dans « la nature ». La meilleure solution est d’utiliser le SSH mais comme Julien ne possède pas d’accès sur ma machine, il y avait toujours un problème… Le problème fut résolu par la mise en place de GITOLITE. Grâce a GITOLITE, je peux donner à n’importe quelle personne un accès sur le projet voulu.

Installation de GITOLITE

Dans l’article concernant l’installation de git, j’ai pu mettre en place un utilisateur « Git ». Cette utilisateur trouve tout son intérêt dans l’utilisation de GITOLITE.  Celui-ci n’a pas besoin de mot de passe car à chaque fois que l’on ajoutera un utilisateur virtuel celui devra fournir une clé publique. Cette clé publique sera ajoutée dans les authorization keys de l’utilisateur Git. Regardons le contenu de mon fichier (authorization keys) :

# gitolite start
command="/home/git/gitolite/src/gitolite-shell pierre",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC70+f4qTYTjAAwG5jjn3emRdbX2S/OccZdYg2QHGc+OL5uW+mitSvwh0wnKJYc3QzzgQ0E/GGpJkTGpzcKaFrz21lPPbjXvUb5Qa8KP11cUCcN5SREKuQem1EMCnUQGrDS94MZ1eFyma0kWGpjWXNCfaRuBcpPfh9WJ1TzTrb0jokGKFloAlzvd0Z5GGzWAWLrTlK7wIVY3Zsvde+kxJJDZkDFm3X/maOdG3Kb/EoTAH1TtG3OkDsoMu/FUogxix6eCMo5g/xREzQxXPyXHxmjY5dCfNVvg7sXx4Ss4jBz9/8vOpbPdEHykjtHBq9L38hbcfYiss4Ab4E0IC2dP+29 pierre@portable
# gitolite end

Cette clé publique correspond à l’utilisateur Pierre.

Pour cela j’ai du générer une paire de clés pour mon utilisateur Pierre. Voici la procédure :

cd ~/.ssh
ssh-keygen -t rsa -f id_rsa_git
cd -
scp id_rsa_git.pub monuser@leServeur:/home/monuser

On se connecte sur notre serveur :

cp id_rsa_git.pub /home/git/pierre.pub
exit

Attention
Lors de mes recherches sur internet pour installer git & gitolite, j’ai pu m’apercevoir qu’il existe deux erreurs récurrentes sur plusieurs sites, la deuxième dépendant de la première.

Cette première erreur consiste à générer une paire de clés pour l’utilisateur Git. En plus de générer une paire de clé qui sera très peu utilisée celle-ci sera mal gardée, c’est pour cela que c’est déconseillé par la communauté Gitolite.

La deuxième erreur est d’ajouter la clé id_rsa_git.pub dans le fichier ~.ssh/authorized_keys:
cat id_rsa_git.pub >> /home/git/.ssh/authorized_keys

Lorsque nous passons à l’installation, nous avons une alerte : WARNING: keydir/git.pub duplicates a non-gitolite key, sshd will ignore it

Si on laisse cela dans l’état, nous n’utilisons pas le shell de Git mais notre shell par défaut (dans mon cas ksh pour mon serveur).

Cependant, si vous désirez que votre utilisateur accède au shell ksh, il est préférable de générer une autre paire de clés.

Installation de GITOLITE

On se connecte sur notre utilisateur git :

# su - git

Puis on récupère GITOLITE :

git clone git://github.com/sitaramc/gitolite

On récupère le chemin en entier :

$ gitolite/install
use the following full path for gitolite:
        /home/git/gitolite/src/gitolite

Puis on effectue l’installation (vous remarquerez que j’ai mis ma clé publique)

$ /home/git/gitolite/src/gitolite setup -pk /home/git/pierre.pub
Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/
Initialized empty Git repository in /home/git/repositories/testing.git/

Configuration de notre client

La configuration de GITOLITE est simple, celui-ci est gérée de la même manière qu’un dépot Git.

Configurons, maintenant, notre poste client afin que cela soit plus simple:

Éditons notre fichier de configuration SSH (vim ~/.ssh/config)

Host gitolite
	User git
	Hostname IP_DE_MON_SERVEUR
	port 22
	identityfile ~/.ssh/pierre

Si la configuration ci-dessous n’est pas effectuée pour se connecter au serveur, il faudrait faire :

 git clone ssh://git@monServeur/gitolite-admin.git/

Sinon vous avez effectué la configuration du SSH, et vous pouvez utilisé soit la première ou deuxième ligne :

git clone ssh://gitolite/gitolite-admin.git/
git clone gitolite:gitolite-admin.git

De vous à moi, je préfère largement la deuxième qui est beaucoup plus simple.

Configuration de notre GITOLITE

On regarde les fichiers récuperés sur notre poste :

ls -R gitolite-admin/
gitolite-admin/:
conf  keydir
 
gitolite-admin/conf:
gitolite.conf
 
gitolite-admin/keydir:
git.pub

On peut voir le fichier gitolite.conf et le repertoire keydir.

Le fichier gitolite.conf permet la configuration des utilisateurs/groupes et les dépôts.
Le répertoire keydir contient les clés publiques des utilisateurs sous la forme nom.pub

Dans le fichier de configuration, on peut avoir plusieurs ACL pour chaque répertoire:

  • RW+ : Droits de lecture, d’écriture et de suppression d’objets particuliers tels que Branches et Tags.
  • RW : Droits de lecture et d’écriture (push)
  • R : Droit de lecture (pull,clone,fetch)
  • – : Refuser l’access (par exemple, on ajoute un groupe mais on veut refuser un utilisateur)

Pour chaque répertoire,  on peut spécifier des utilisateurs, des groupes ou bien un accès public.

Ajout d’un utilisateur

Il suffit de copier la clé publique dans le répertoire keydir récupéré en local. Prenons l’exemple de Julien :

Julien me donne sa clé publique.

cp julien.pub keydir/

On ajoute la clé dans le répertoire :

git add julien.pub
git commit -m "Ajout de l'utilisateur Julien"

Nous venons de soumettre le projet dans le répertoire local. Afin de le rendre disponible sur le serveur de référence, il faut donc effectuer un push:

git push

Création d’un répertoire oversimple :

Il faut ajouter dans conf/gitolite.conf :

repo oversimple
	RW+	= pierre julien

Création de plusieurs répertoires pour les mêmes personnes, rien de plus simple :

repo oversimple oversimple1 oversimple2
	RW+ = pierre julien

Une fois les modifications apportées, les commandes sont toujours pareilles :

$ git add conf/gitolite.conf
$ git commit -m "Ajout du répertoire oversimple"
$ git push
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 398 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
remote: Initialized empty Git repository in /home/git/repositories/oversimple.git/
To ssh://gitolite/gitolite-admin.git
   8039b66..f2b18d1  master -&gt; master

On peut remarquer la création de notre répertoire oversimple.git.

Création de groupe :

Julien et moi formons un groupe qui est oversimple. Pour les projets que l’on peut avoir en cours, d’autres personnes peuvent se greffer, par exemple, Éléonore.
Ajout dans la configuration :

@oversimple = pierre julien
OU Exactement pareil :
@oversimple = pierre
@oversimple = julien
 
repo oversimple oversimple1 oversimple2
	RW+ = @oversimple
 
repo projet1
	RW+ = @oversimple
	RW = eleonore

Bien sur une clé publique sera ajoutée pour Éléonore

Une fois terminée, toujours la même musique… git add, commit & push.

Pour terminer, testons un peu les différents droits. Mettons nous dans le cas d’ Éléonore, celle-ci a accès uniquement au répertoire projet1.

$ git clone leo:projet1
Cloning into 'projet1'...
warning: You appear to have cloned an empty repository.

Cela fonctionne parfaitement. Cependant, elle aimerait avoir accès au dossier oversimple.

$ git clone leo:oversimple
Cloning into 'oversimple'...
FATAL: R any oversimple eleonore DENIED by fallthru
(or you mis-spelled the reponame)
fatal: The remote end hung up unexpectedly

On peut voir qu’elle n’y a pas accès, car elle n’est pas présente dans la configuration.

Nous avons un Git & GITOLITE opérationnel !

It’s over simple, isn’t it?

Installation de GIT sous OpenBSD

Pour rappel, Git est un logiciel de versions décentralisées. C’est un logiciel libre créé par Linus Torvalds.

Son fonctionnement est simple :

Git indexe tous les fichiers en effectuant un SHA-1 sur chaque fichier. Si un fichier est modifié, le SHA-1 sera différent et donc Git stocke en plus la nouvelle version. De plus, si le SHA-1 est identique alors c’est que le fichier n’est pas modifié.

Installation de Git

Passons à l’installation sous OpenBSD 5.1, rien de bien compliqué :

# pkg_add -i git

Ajoutons un utilisateur, celui-ci permettra:

  • D’exécuter le daemon Git.
  • De pouvoir se connecter en SSH avec un utilisateur différent pour son système. (Évolution avec Gitolite)
  • D’ordonner ses répertoires, si on travaille sur un même système, il est intéressant qu’un utilisateur soit créé pour gérer l’ensemble des projets.
 # adduser git

Client

Avant de passer à l’utilisateur du serveur Git, nous allons configurer notre client:

Mettons de la couleur dans Git grâce aux commandes suivantes :

$ git config --global color.diff auto
$ git config --global color.status auto
$ git config --global color.branch auto

Puis, on configure notre identifiant (pour ma part,  mon prénom) ainsi que l’adresse mail:

$ git config --global user.name Pierre
$ git config --global user.email pierre@oversimple.fr

De plus, des alias peuvent être mis en place. Par exemple pour « Git commit » on peut faire un « Git ci »:

git config --global alias.ci commit

La configuration ci-dessus est présente dans le fichier .gitconfig. Il se trouve dans notre répertoire personnel.

$ cat ~/.gitconfig
[color]
        diff = auto
        status = auto
        branch = auto
[user]
        name = Pierre
        email = pierre@oversimple.fr
[alias]
        ci = commit

Utilisation du serveur Git

Créons notre projet Git :

$ mkdir monProjet
$ cd monProjet
$ git init

Notre répertoire étant créé, il existe plusieurs méthodes disponibles pour travailler avec Git:

  • Clone en local : git clone monProjet monProjetDeTravail
  • Clone grâce au daemon git :
    1. Exécuter le daemon git (sur le serveur): /usr/local/libexec/git/git-daemon –verbose –base-path=/home/pierre/git/
    2. Récupérer le dépôt sur le poste client : git clone git://monServeur/monProjetgestion
  • Clone via SSH :git clone ssh://git@monServeur/monProjet

 

Pour ajouter un fichier :

 $ git add nomFichier

Pour ajouter le contenu d’un répertoire:

 $ git add monRepertoire/

Pour ajouter tous les nouveaux fichiers (ou les modifier):

 $ git add .

On peut aussi supprimer un fichier ou un répertoire:

$ git rm nomFichier
$ git rm -r monRepertoire/

On commit notre changement (ajout/modification/suppression) :

 $ git commit -m "Ajout du nomFichier"

Retourner au dernier commit :

 $ git reset --hard HEAD

Visualiser les logs des différents commits:

 $ git log

On envoie les modifications sur le serveur afin qu’elles soient disponibles pour les autres utilisateurs, la première fois :

 $ git push origin master

Puis après :

 $ git push

Mettre à jour son dépôt local :

 $ git pull

Il existe plein d’autres possibilités; notamment la gestion des différentes branches.

It’s over simple, isn’t it?

Mais au faite qu’est ce qu’un honeypot ?


Un de nos amis qui suit activement les débuts d’OverSimple nous a fait remarquer qu’il manquait une définition du Honeypot.

Un honeypot peut aussi être défini comme un pot de miel. Les honeypots sont notamment connus dans le monde de la sécurité informatique. Ils ont pour but de faire croire à l’attaquant que l’ordinateur est vulnérable afin de le piéger et de l’attirer.

Cela permettra à l’administrateur :

  • D’étudier les différentes attaques possibles contre son propre réseau
  • De surveiller les attaques contre son Honeypot afin de s’en prémunir
  • D’étudier de nouvelles attaques possibles qui ne sont pour l’instant pas reconnu

 

On peut déduire deux types d’honeypots :

  • Le premier est basé sur les serveurs actuellement mis en production (notamment pour une entreprise)
  • Le second est utilisé afin d’étudier de nouveaux types d’attaques.

De plus, il existe des honeypots à faible, moyenne et forte interaction.

Pour les honeypots à faible interaction, cela peut être représenté par la commande netcat. A part l’identification des machines sur le réseau, l’honeypot n’est pas capable d’interagir comme pour un vrai système.

Les honeypots à moyenne intéraction représente la limite entre deux types d’honeypots: les honeypots à faible intéractions qui permettent juste de simuler une machine et les honeypots à forte interaction où on peut interagir comme un vrai système.

Enfin, les honeypots à forte interaction permettent de simuler quasiment un vrai système.

Bien sûr, en terme de sécurité, ils sont tous différents. Plus il y a de possibilités pour un attaquant, plus la machine est non fiable.

Les honeypots peuvent intervenir sur plusieurs services notamment :

SSH, HTTP, SMB, SMTP, IMAP, FTP, HTTPS, KERBEROS, MS-SQL, DNS, WEBMIN …

 

Et plein d’autres honeypots présents sur différents protocoles !