Étiquette : ssh

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?

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 -> 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?

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 !

Mise en place d’un Honeypot SSH à domicile (kippo)

L’Honeypot SSH qui a été mis en place est Kippo.

Pourquoi choisir kippo ?

  • écrit en python
  • moyenne interaction avec l’attaquant.
  • possibilité d’ajouter des fonctions pour encore plus d’interaction !
  • une petite communauté derrière assez sympa !

Le Système hôte est mon serveur personnel; celui-ci est basé sur OpenBSD. Pour mes épreuves de BTS, j’avais déjà mis en place un Honeypot. Celui-ci avait tourné plus de 2mois. Après une nouvelle configuration sur mon serveur, je n’avais pas remis en place l’Honeypot. Cependant, je gardais les IP bannis soit 1379 en 10 mois, pour un serveur personnel n’hébergeant rien de particulier je trouve ça assez conséquent.

Installation des dépendances :

pkg_add -i subversion apr-util cyrus-sasl py-twisted-core py-twisted-conch py-asn1 py-twisted-web py-mysql

Une fois les dépendances installées, on récupère Kippo.

svn checkout http://kippo.googlecode.com/svn/trunk/ honeypots/

Kippo n’étant pas configuré au départ, il faut renommer son fichier de configuration :

mv kippo.cfg.dist kippo.cfg

Pour l’instant, dans ce fichier nous changeons le nom de la machine visible par l’attaquant. (hostname = simple)

De plus, on peut changer le port de l’honeypot, par défaut, port 2222.

Si on désire mettre le port 22, qui est le port SSH par défaut, il faut exécuter kippo en root… ou simplement rediriger le port 22 vers le port 2222 avec packet-filter. C’est cette option que nous allons adopter pour son élégance.

Éditons le fichier de configuration packet-filter :

pass in quick on $ext proto tcp from any to ($ext) port 22 rdr-to ($ext) port 2222

$ext correspond a mon interface réseau.

Après cette étape, si on désire on peut déja rendre disponible Kippo :

start.sh

Cependant, nous allons mettre en place une base de données MySQL afin de réaliser des statistiques sur les différentes attaques.

create database kippo;

use kippo;

source honeypot/doc/sql/mysql.sql

Créer l’utilisateur avec le minimum de droit (SELECT, INSERT, UPDATE) :

GRANT SELECT, INSERT, UPDATE ON kippo.* TO ‘kippo’@’localhost’ IDENTIFIED BY ‘mot de passe’;

La base de données étant configurée, modifier les lignes dans le fichier de configuration de Kippo afin que celui-ci utilise la base MySQL.

 [database_mysql]

host = IP Du Serveur MySQL

database = kippo

username = kippo

password = mot de passe

De plus, on peut modifier le fichier de configuration :

sensor_name=serveurMaison

Afin que dans la base de données, on puisse apercevoir le nom de l’honeypot utilisé. Cela peut être utile, si un jour on décide d’ajouter un autre kippo sur un autre serveur SSH. Il faudra juste configurer la base de données !

Démarrons Kippo est attendons les attaques !

$ tail -f log/kippo.log
2012-05-05 17:54:11+0200 [-] Log opened.
2012-05-05 17:54:11+0200 [-] twistd 11.0.0 (/usr/local/bin/python2.7 2.7.1) starting up.
2012-05-05 17:54:11+0200 [-] reactor class: twisted.internet.selectreactor.SelectReactor.
2012-05-05 17:54:11+0200 [-] kippo.core.honeypot.HoneyPotSSHFactory starting on 2222
2012-05-05 17:54:11+0200 [-] Starting factory <kippo.core.honeypot.HoneyPotSSHFactory instance at 0x84e3e46c>

En attendant voici un aperçu des différents répertoires de kippo :

  • dl : Fichiers téléchargés par les attaquants (wget).
  • log/kippo.log : Permet de debugger en cas de problème ou de voir en direct les attaques.
  • log/tty : Répertoire contenant les différentes sessions des attaquants. Possible de le visionner avec : utils/playlog.py
  • honeyfs : Contient les différents fichiers pour le fakesystem !

 

It’s over simple, isn’t it?