mardi 6 septembre 2011

XFS et les Quota de projets

Il peut être parfois pratique de pouvoir gérer les quotas des utilisateurs en fonction du dossier et non de l'utilisateur ou du groupe auquel il appartient.

L'une des solutions consiste à utiliser le système de fichier nomme "XFS". En effet, il permet la mise en place quota de projet ( c'est le nom utilisé pour désigner l'application de quotas sur des dossiers).

Une fois le système fichier installé, il faut ajouter deux paquets permettant la gestion des quotas :

# apt-get install xfsprogrs xfsdump

puis il faut ensuite aller modifier le fichier "/etc/fsttab" afin de rajouter au système de fichier l'option "prjquota". La ligne de votre fichier doit ressembler à :

# <file system> <mount point> <type> <options> <dump> <pass>

# /home was on /dev/sdb6 during installation

UUID=f9a6b742-1131-4d5a-aa09-fc9514379ef4 /home xfs defaults,prjquota 0 2

Il faut ensuite utiliser quelques commandes afin d'ajouter un quota. On notera qu'XFS_quota utilise sa propre commande.

  • déclarer un quota de projet dans "/etc/projects" en associant au dossier à limiter un identifiant de projet :

echo 1:/home/a-hyaric >> /etc/projects

  • affecter un nom (« prrjtest ») en lien avec ce même identifiant de projet dans le fichier "/etc/projid" :

echo prjtest:1 >> /etc/projid

  • enregistrer le quota de projet auprès du système de fichier :

xfs_quota -x -c 'project -s prjtest' /home

  • mettre en place la limite de quota (20m ici):

xfs_quota -x -c 'limit -p bhard=20m prjtest' /home

La mise en place des quotas peut être vérifier grâce à la commande : xfs_quota -x -c report /home 2>/dev/null

Source : ici

Samba Logs

La création d'un partage Samba a déjà été évoqué précédemment.

Une fois les différents partages et contrôle d'accès mis en place, il peut être intéressant d'avoir des logs clairs permettant de suivre l'activité des différents partages. En effet, par défaut, Samba regroupe ses logs dans plusieurs fichiers(1 par utilisateur et machine), et il peut être fastidieux de les parcourir et d'y trouver la bonne information. La solution préconisée par Samba est l'utilisation de . Le module le plus précis et paramétrable est .

Il vous suffit alors de compléter le fichier smb.conf de la manière suivante :

#======================= Global Settings =======================
[global]

       log level = 1 vfs:10
       vfs objects = full_audit
       full_audit:prefix = %u|%I|%m|%S
       full_audit:success = mkdir rename unlink rmdir pwrite
       full_audit:failure = none
       full_audit:facility = LOCAL7
       full_audit:priority = NOTICE

# penser à commenter les lignes suivantes :
# log file = /var/log/samba/%U.%m.log
# syslog only = yes
# syslog = 2

Les déclarations du module sont mises dans la section globale mais peuvent être également placées dans chaque partage.

Un peu d'explication à propos des déclarations :

  • la ligne "log level" : elle permet de préciser le niveau des logs (1 donnant le minimum d'informations utiles et 10 le maximum). Ici, on met le niveau global des logs de samba à "1" et celui du module à "10".
  • la ligne "vfs objects" : elle permet de déclarer l'utilisation du module full_audit sur tous les partages
  • la ligne "full_audit:prefix" : elle spécifie la syntaxe des lignes de logs (les samba peuvent être utilisées). Cette ligne donnera alors le nom d'utilisateur, l'adresse IP du client, le nom de la machine et le partage accédé, séparés par des pipes.
  • la ligne "full_audit:prefix" : elle permet de spécifier les à enregistrer.
  • la ligne "full_audit:failure" : de même avec les actions échouées
  • la ligne "full_audit:facility" elle permet d'attribuer une instance du syslog (1)
  • la ligne "full_audit:priority" : elle permet d'attribuer l'importance des messages (dans l'ordre d'urgence : EMERG, ALERT, CRIT, ERR, WARNING, NOTICE, INFO, DEBUG)
(1) Créer une instance du syslog

Pour créer une nouvelle instance du syslog, il faut aller modifier le fichier de configuration /etc/rsyslog.conf afin d'y rajouter :

       #creating a syslog facility
       local7.*        /var/log/samba/log.audit

Ce qui signifie que tous les messages de local7 seront écrit dans /var/log/samba/log.audit (qui devient alors notre fichier d'audit principal). Il faut ensuite redémarer le démon syslog pour prendre en compte les changements (avec /etc/init.d/rsyslog restart).

Exemple du fichier log.audit :
     Aug  4 16:46:04 localhost smbd[29819]: a-hyaric|172.18.60.233|cnu85175wc|a-hyaric|pwrite|ok|~$uveau Document Microsoft Word.docx
     Aug  4 16:46:12 localhost smbd[29819]: a-hyaric|172.18.60.233|cnu85175wc|a-hyaric|rename|ok|./93DC53A7.tmp|./Nouveau Document Microsoft Word.docx
     Aug  4 16:47:37 localhost smbd[29819]: a-hyaric|172.18.60.233|cnu85175wc|a-hyaric|unlink|ok|Copie de favicon.ico

Source : ici

DFS et samba

La création d'un partage Samba a déjà été évoqué précédemment.

Samba permet d'utiliser l'architecture Microsoft DFS permettant de regrouper des partages de différents serveurs sous un même partage appelé racine DFS.

Cela peut permettre de regrouper tous les liens des partages sous un seul partage réseau pour les utilisateurs ou encore de permettre une "double authentification" (la racine DFS ayant sa propre liste d'utilisateurs autorisés).

Par exemple, dans une entreprise ayant 3 partages (HR, Logistique, Compta) sur respectivement 3 serveurs de fichiers (srv1, srv2, srv3) sur 3 sites différents (172.18.10.251, 172.18.20.252, 172.18.30.253), il est alors possible de regrouper tous ses partages sous un seul partage sur un serveur. Les utilisateurs n'auront plus qu'à monter le lecteur réseau commun pour avoir accès ensuite aux différents partages. Il est également possible de mettre une racine DFS dans un racine DFS et ainsi de suite.

Il suffit pour cela d'abord modifier le fichier smb.conf :

#======================= Global Settings =======================

[global]

       host msdfs = yes

...

#======================= Share Definitions =======================

[nom_du_partage]

       msdfs root = yes
       path = /chemin/vers/le/dossier

Il faut ensuite aller dans le dossier de la racine DFS et faire un lien DFS :

# ln -s msdfs:adresse_serveur\\nom_partage_distant nom_local

Exemple de script permettant d'automatiser la création des liens DFS : symlink_DFS

Il se peut que vous rencontriez des erreurs lors de l'utilisation des DFS avec Samba 3.5.6, un passage à Samba 3.5.8 ou 3.5.9 peut résoudre vos problèmes.

lundi 29 août 2011

CloneZilla : serveur de ghost

Un serveur de Ghost permet de faire une copie d'une machine et de la déployer sur d'autre machines, de faire une remise à plat de votre de machine dans les délais les plus bref, sans devoir tout refaire à la mains. Vous lancer le ghost, allez boire un café, et de retour vous recommencez à travailler ;)

Lire la suite...

jeudi 25 août 2011

Sauvegarde des config des équipements réseaux

Il existe un petit outil pour automiser ce job chiant,et en plus facile a installer et à configurer: http://www.shrubbery.net/rancid/

Voici quelques tutos où on retrouve toutes les infos utiles:
Tuto d'installation
Utilisation de SVN au lieu CVS

samedi 20 août 2011

Kippo - Honeypot SSH

Présentation

Kippo <http://code.google.com/p/kippo/> est un honeypot SSH. Il permet de simuler un serveur SSH qui, suivant l'objectif, peut être facilement accessible lors d'une tentative d'attaque sur le serveur hôte. Il permet, entres autres, de récupérer certaines informations de l'attaquant :

  • les couples logins / mots de passe utilisés pour s'authentifier ;
  • une fois authentifié, les commandes utilisées ;
  • les fichiers envoyés par l'attaquant ;
  • et bien d'autres...
Il est codé en python et nécessite quelques librairies pour fonctionner (en plus du moteur Python bien évidemment) :
  • Twisted 8.0+ (paquet : python-twisted-bin)
  • PyCrypto (paquet : python-crypto)
  • Zope Interface (paquet : python-zope.interface)

Installation

L'installation est vraiment simpliste :

$ wget http://kippo.googlecode.com/files/kippo-0.5.tar.gz
$ tar xzf kippo-0.5.tar.gz && rm kippo-0.5.tar.gz && cd kippo-0.5
$ ./start.sh

et voilà :)

Par défaut, le serveur SSH sera lancé sur le port 2222. Ce port peut être modifié dans le fichier de configuration kippo.cfg:

15|    ssh_port = 2222

Attention néanmoins, Kippo refusera de se lancer avec des droits root, ce qui est très compréhensible, donc il ne sera pas possible de désigner un port inférieur à 1024 (il faudra alors privilégier le port-forwarding afin que le service soit à l'écoute sur le port 22).

Informations et modifications

Plusieurs dossiers sont intéressants

  • honeyfs : il contient l'arborescence des fichiers du serveur SSH. Il est ainsi possible de configurer un /proc/meminfo comme désirer par exemple ;
  • txtcmds : il contient le retour de plusieurs commandes, encore une fois pour personnaliser l'environnement de l'attaquant ;
  • log : il contient le fichier de log du serveur, qui enregistre en particulier les couples logins/passwords et les commandes tapées ;
  • dl : il va contenir tous les fichiers envoyés par l'attaquant.

Récupération des logins et mots de passe

Notre objectif maintenant serait de récupérer dynamiquement, et séparément les logins et mots de passe utilisés (par exemple pour pouvoir se confectionner un petit dictionnaire).
Plusieurs solutions sont possibles :

1 - L'extraction à partir du fichier de logs

Ca ne sera pas du tout dynamique ni probant, mais voici un petit script rapidement écrit pour extraire les IP, les logins et les mots de passe :

#!/bin/bash
#
for ll in $(egrep -o "([[:digit:]]{1,3})(.)([[:digit:]]{1,3})(.)([[:digit:]]{1,3})(.)([[:digit:]]{1,3})(.)(\])( login attempt )(\[)([[:print:]]+)(/)([[:print:]]+)(\])" kippo.log | cut -d' ' -f1,4 -s --output-delimiter=)
do
        IP=$(echo $ll | cut -s -d']' -f1)
        LOGIN_PASS=$(echo $ll | cut -s -d'[' -f2 | cut -s -d']' -f1)
        LOGIN=$(echo $LOGIN_PASS | cut -s -d'/' -f1)
        PASS=$(echo $LOGIN_PASS | cut -s -d'/' -f2)

        ## Logs
        echo $IP >> tempIPs
        echo $LOGIN >> tempLOGINs
        echo $PASS >> tempPASSWORDs

        echo "IP: $IP -- Login: $LOGIN -- Password: $PASS"
done

## Logs globaux
for name in IPs LOGINs PASSWORDs
do
        uniq "temp$name" >> $name
        rm "temp$name"
done


2 - L'enregistrement automatique

Autre solution un peu plus propre est de modifier directement le code source de Kippo afin que, à chaque tentative de connexion, le couple login/mot de passe soit enregistré dans un fichier :

Modification du fichier kippo/core/honeypot.py

## Ouverture du flux vers les deux fichiers
19 > logsLogins = open('log/logins.log', 'a');
19 > logsPasswd = open('log/passwd.log', 'a');

## Ne pas vérifier le login à l'authentification
## Sinon, le fichier log/logins.log ne contiendrait que 'root' :s
## Je laisse quand même la vérification pas mot de passe, ce dernier, modifié, étant très complexe, afin de me laisser une porte au besoin
440 < if username == 'root' and password == cfg.get('honeypot', 'password'):
440 > if password == cfg.get('honeypot', 'password'):

442 < elif username == 'root' and password in passdb:
442 > elif password in passdb:

445 > logsLogins.write(username)

445 > logsPasswd.write(password)
445 > logsLogins.flush()
445 > logsLogins.flush()


(fichier d'exemple joint à ce billet)

Le résultat après une tentative / attaque :
  • Concernant les commandes

$ cat log/kippo.log
[...]
2011-08-19 23:05:43+0200 ... ,89.158.96.199] channel open
2011-08-19 23:05:43+0200 ... ,89.158.96.199] pty request: xterm (24, 80, 0, 0)
2011-08-19 23:05:43+0200 ... ,89.158.96.199] Terminal size: 24 80
2011-08-19 23:05:43+0200 ... ,89.158.96.199] getting shell
2011-08-19 23:05:43+0200 ... ,89.158.96.199] Opening TTY log: log/tty/20110819-230543-4519.log
2011-08-19 23:06:19+0200 ... ,89.158.96.199] CMD: cat /proc/cpuinfo
2011-08-19 23:06:19+0200 ... ,89.158.96.199] Command found: cat /proc/cpuinfo
2011-08-19 23:06:19+0200 ... ,89.158.96.199] Updating realfile to honeyfs//proc/cpuinfo
2011-08-19 23:09:06+0200 ... ,89.158.96.199] CMD: ifcondif
2011-08-19 23:09:06+0200 ... ,89.158.96.199] Command not found: ifcondif
2011-08-19 23:09:10+0200 ... ,89.158.96.199] CMD: ifconfig
2011-08-19 23:09:10+0200 ... ,89.158.96.199] Command found: ifconfig
2011-08-19 23:09:10+0200 ... ,89.158.96.199] Reading txtcmd from "/tmp/kippo-0.5/txtcmds/sbin/ifconfig"
2011-08-19 23:10:26+0200 ... ,89.158.96.199] CMD: cat /proc/meminfo
2011-08-19 23:10:26+0200 ... ,89.158.96.199] Command found: cat /proc/meminfo
2011-08-19 23:11:19+0200 ... ,89.158.96.199] CMD: ifconfig
2011-08-19 23:11:19+0200 ... ,89.158.96.199] Command found: ifconfig
2011-08-19 23:11:19+0200 ... ,89.158.96.199] Reading txtcmd from "/tmp/kippo-0.5/txtcmds/sbin/ifconfig"
2011-08-19 23:11:32+0200 ... ,89.158.96.199] CMD: ifconfig
[...]

$ cat log/passwd.log
[...]
00ad82
00AL09
00al74
00B430
00bd
00beaba
00beca
00bn23
00bob
00C737
00chr2
[...]

mercredi 3 août 2011

Asterisk et Asterisk-GUI sous Debian

(sur Debian Squeeze 64 bits)

Installation de Asterisk

  • apt-get install asterisk

Dans /etc/asterisk/manager.conf :

enabled = yes
webenabled = yes

[admin]
secret = adminpw
read = system,call,log,verbose,command,agent,user,config
write = system,call,log,verbose,command,agent,user,config

Et dans /etc/asterisk/http.conf :

enabled=yes
enablestatic=yes
bindaddr=0.0.0.0 (commenter le 127.0.0.1)

Puis en user normal :

  • svn checkout http://svn.digium.com/svn/asterisk-gui/trunk asterisk-gui
  • cd asterisk-gui
  • ./configure
  • make

En root :

  • make install

Petit soucis : les fichiers sont copiés dans /var/lib/asterisk/ alors que l'installation d'Asterisk ous Debian va chercher dans /usr/share/asterisk/.

Heureusement, la solution est trouvable. (Source : http://androus.wordpress.com/2009/12/26/asterisk-gui-2-0-404-url-not-found-fedora/)

  • cp -Rfv /var/lib/asterisk/* /usr/share/asterisk/
  • mv /var/lib/asterisk /var/lib/asterisk_original
  • ln -s /usr/share/asterisk /var/lib/asterisk

Penser à redonner les bons droits :

  • chown -R asterisk:asterisk /usr/share/asterisk

/etc/init.d/asterisk restart et zou :

http://<ip_du_pbx>:8088/static/config/index.html

samedi 14 mai 2011

Le Lama

Un jour de beau temps, nous avons décidé de jouer aux cartes. Après une bataille endiablée et plus la motive de jouer à ce jeu de m**** on a décidé de jouer a autre chose, un jeu de ouf, un jeu endiablé avec des lamaseries, des coups de pavute et autre joyeuseté bien vile. De ce mélange est né le Lama !

Le lama se joue de 2 à moulte joueurs avec minimum un jeu de carte puis autant que l'on veux plus on est à jouer. Il est préférable de jouer avec les jokers, mais pas obligatoire. De 2 à 4, vous pouvez jouer avec un jeu, de 4 à moulte il est recommandé de jouer avec minimum deux jeux.

Les règles sont assez simples:

Le donneur distribue 8 cartes (qui forment la main) une par une à chaque joueur, les cartes qui restent forment la pioche. Pour commencer le jeu, on retourne la première carte de la pioche face visible sur la table pour créer le tas.

Le premier à jouer est la personne qui se trouve à gauche du donneur.

Le but du jeu est de se défausser sur le tas de toutes ses cartes le premier. Pour se faire, on joue les cartes que l'on a en main en fonction de la couleur ou de la valeur de la dernière carte posée sur le tas (si c'est un 6 de cœur, je peux jouer n'importe quel cœur ou un n'importe quel 6). Si dans la main il n'y a pas de carte jouable, on pioche alors une carte. Si la carte piochée est jouable, il est possible de la jouer ou non. Puis c'est au joueur situé à gauche de jouer, et ainsi de suite. initialement on joue donc dans le sens horaire.

Simple et efficace comme principe, mais pas non plus folichon. Pour ce faire on ajoute quelques exceptions :)

La carte 2 : Quand on pose un deux, la prochaine personne à jouer prendra automatiquement 2 cartes de la pioche pour les mettre dans sa main et ceci avant de jouer quoi que ce soit. Si il s'agit d'un deux de pique, la personne prendra alors 4 cartes avant de jouer.

La carte 8 : la carte 8 fais changer le sens de jeu. Si on tourne à gauche, après la pose, on tournera à droite jusqu'au prochain changement de sens.

Le Joker (ou une autre carte si vous n'en avez pas): Le joker permet de faire changer la couleur en cour quelque soit la carte qui la précède. Si vous poser un joker sur un 4 de pique, vous pouvez demander à ce que cela passe en carreau, et les joueur qui vous suivent devront jouer en carreau.

Voici les règles de base du Lama. Celles ci sont toujours vraies avec un seul ou plusieurs jeu de carte. Mais quand il y a plusieurs jeu de carte, on ajoute une règle supplémentaire :

Le double : Quand la carte que l'on pose est identique à la carte précédemment posé, quelque soit la carte,la personne qui joue après prend automatiquement une carte. La où cela devient drôle c'est avec les 2. Quand on pose un deux sur un deux (déjà on se mange 2 ou 4 cartes), la personne qui suit prendra la carte du double plus le nombre de carte imputé au deux cartes qui sont en dessous . Si je pose un deux de cœur sur un autre deux de cœur, le joueur suivant prendra donc 5 cartes (1+2+2) pour un deux normal, et donc 9 cartes pour un deux de pique (1+4+4) ;) à noter que s'il y a plus de deux jeux de carte on ne compte pas au delà de 2 cartes (même si 3 cartes identiques se suivent).

jeudi 10 mars 2011

Ajaxterm : un client SSH en web

Petite présentation

J'ai enfin trouvé un client web qui me permette de prendre la main sur mes serveurs quand je n'ai pas de client SSH accessible ou que les ports (généralement le 22) sont bloqués. Son nom : Ajaxterm.
Le site de l'âme charitable qui nous le met à disposition : http://antony.lesuisse.org/software/ajaxterm/

Installation

L'installation sous Debian est très simple, Ajaxterm étant disponible dans les dépôts. On commence donc par un classique "apt-get install ajaxterm" pour installer Ajaxterm et les dépendances qui vont bien, en particulier Apache. Attention toutefois, ceci installe la version 0.7. La dernière version lors de l'écriture de ce billet est la 0.11.

Configuration

Le serveur Ajaxterm est écrit en Python et écoute sur le port 8022 en local. Vous pouvez d'ores et déjà vérifier son fonctionnement en lançant un w3m (ou n'importe quel navigateur) à l'adresse http://localhost:8022/. Si besoin, le port peut être modifié dans /etc/default/ajaxterm.

Pour activer un accès depuis une autre machine, on peut ajouter un vhost à Apache qui se contentera de rediriger les requêtes vers Ajaxterm, par le biais du module mod_proxy. Évidemment, ce vhost devra être accessible en HTTPS si on veut conserver l'avantage du chiffrement SSL/TLS.

Cette fonctionnalité nécessite d'activer les modes mod_proxy, mod_proxy_http et mod_ssl :
a2enmod ssl
a2enmod proxy
a2enmod proxy_http

Génération d'un certificat auto-signé

Pour avoir un accès en SSL on peut utiliser un certificat existant ou générer un certificat auto-signé :
make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/ssl/ajaxterm.crt
Bien évidemment, ce certificat auto-signé lèvera une erreur dans le navigateur. Il est préférable de le signer avec un certificat racine approuvé par le navigateur.

Ajout d'un vhost Apache

On crée donc un /etc/apache2/sites-available/ajaxterm que l'on paramètre pour rediriger les requêtes de /ajaxterm/ vers le port 8022 :

<VirtualHost *:443>

ServerName localhost
SSLEngine On
SSLCertificateFile /etc/ssl/ajaxterm.crt
ProxyRequests Off

<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass /ajaxterm/ http://localhost:8022/
ProxyPassReverse /ajaxterm/ http://localhost:8022/

</VirtualHost>

Et on l'active :
a2ensite ajaxterm
Et là youpi ! En pointant un navigateur vers https://IP_du_serveur/ajaxterm/ on peut ouvrir une session SSH sur le serveur.

Augmentation du timeout de la session

Par défaut, votre session SSH se terminera après deux minutes d'inactivité. Je n'ai pas vraiment compris pourquoi mais ce temps peut être augmenté sans problème. Éditons le fichier /usr/share/ajaxterm/ajaxterm.py. À la ligne 395, on remplace modifie la valeur de INACTIVE_PROCESS_TIMEOUT pour le mettre par exemple à 300 secondes (5 minutes). Après un petit redémarrage d'Ajaxterm (/etc/init.d/ajaxterm restart) le nouveau timeout d'inactivité est pris en compte.

Conclusion

Les avantages :

  • Passe les proxy.
  • Simplicité d'installation ;

Les inconvénients :

  • Pas de session SSH vers un autre serveur, uniquement en local ;
  • Pas avec compatible IE7 (ok avec IE8) EDIT 11/03/2011 : en fait si, aujourd'hui ça fonctionne ;
  • Reset de la connexion au bout de 2 minutes d'inactivité (modifiable) ;
  • Nécessite un reverse proxy pour l'atteindre depuis une autre machine. Le paquet ajaxterm dépend d'Apache.

mardi 1 février 2011

Zimbra : les logs ne se font pas

Dans le cas ou Zimbra n'arrive pas a lancer zmlogswatch.

Sous l'utilisateur Zimbra, lancer :
# zmcontrom status

la ligne

logger     Stopped
zmlogswatchctl is not running

regarder dans :
# cat log/zmlogswatch.out

s'il retourne l'erreur :
Error opening /var/log/zimbra-stats.log: No such file or directory at /opt/zimbra/data/tmp/.swatch_script.24725 line 92

créer le fichier :
# touch /var/log/zimbra-stats.log

et relancer zimbra :
# zmcontrol restart

un # zmcontrol status devrait alors afficher :
logger running

si le problème persiste, crée un lien symbolique vers rsyslog pour simuler le syslog :
#ln -s /etc/rsyslog.conf /etc/syslog.conf

et relancer zimbra :
# zmcontrol restart

et voila :)

lundi 31 janvier 2011

Zimbra : Installation

Zimbra est un groupware puissant qui a l'avantage d'avoir une version dite OSE qui est open source sous licence ZLT (Zimbra Licensing Terms).

En plus de faire du mail, il fait aussi calendrier (Caldav), gestion de contact (CardDav), gestion de tache et Porte document. Propose un interface web, le support des protocoles IMAP(S), SMTP(S), POP(S) et est extensible par des plugins. Zimbra propose gratuitement Zimbra Descktop, qui est un client lourd de messagerie qui support toutes les fonctionnalités de Zimbra et est disponible sur Windows, Linux et MAC.

En claire ça fais beaucoup de chose, c'est sur des protocoles standards, c'est gratuit et ça poutre ;p

Nous allons faire cette installe sur une vm Debian 5 fraîchement installé. Les precos pour un serveur de test sont 1Gb de ram, 5Gb de disque. Pour de la prod, le mini est 2Gb de ram et 10Gb de disque.

  • Petite precision : Je fais tourner ça sur un atom, donc je suis obligé de prendre un version 32Bit, mais si vous le pouvez prenez la 64bit. Qui plus est je prend une version Beta, car je la trouve stable et plus légère que la version stable. Faite vos choix :)

1) récupération de Zimbra OSE

# wget http://files2.zimbra.com/downloads/7.0.0_BETA3/zcs-7.0.0_BETA3_2996.DEBIAN5.20101209114956.tgz

2) préparation du serveur : DNS

Il vous faut un DNS qui tien la route pour que cela fonctionne. J'ai passé un certain temps sur les conf en testant de passer par les dns d'un provider, mais sans succès. Je suis donc parti sur un DNS local directement sur le serveur ou l'on installe Zimbra. Ceci dis, si vous avez un DNS dans votre réseaux local, configurez le pour que ça tourne (Je suppose que vous n'avez pas besoin de moi, pour éditer une zone DNS :p )

Sinon regardez ce billet : DNS

3) installation

# tar xvzf zcs-7.0.0_BETA3_2996.DEBIAN5.20101209114956.tgz

# cd zcs-7.0.0_BETA3_2996.DEBIAN5.20101209114956

# ./install.sh

A partir de là, suivez les instructions données pas Zimbra.

Acceptez la licence.

Généralement il manque des paquets, quitez l'installeur de Zimbra et installez les:
# aptitude install sudo libidn11 libpcre3 libgmp3c2 libexpat1 sysstat sqlite3%%

  • Les paquets ci dessus sont valable dans le cas de Zimbra 7beta3 sur une Debian 5, adaptez les en fonction de ce qui est demandé par l'installeur.

Pour une installation simple, laissez le choix des modules par défaut, et acceptez. Zimbra va alors copier ces paquets sur le serveur puis lancer la configuration. La première chose qu'il vous demande concerne le domaine. Par défaut, il prend le nom de la machine comme nom de domaine il faut le changer:
DNS ERROR resolving MX for monserveur.domaine.loc
It is suggested that the domain name have an MX record configured in DNS
Change domain name? [Yes] Yes
Create Domain: [mta.reseau.loc] domaine.loc

Si votre DNS est bien configuré, il valide et passe a la suite, si ce n'est pas le cas, revoyez la config DNS et recommencez.

La seconde chose à faire est de changer le mot de passe par défaut de l'interface d'admin, entrez les commandes suivantes avec appui sur <entrer> entre chanque : 3 ,4
il vous demande alors de changer le mot de passe :
Password for admin@domain.loc (min 6 characters): [mot_de_passe_aléatoire] Mon nouveau mot de passe

Validez et enregistrez la configuration avec la séquence : r, a.
Répondez yes pour enregistrer la configuration
validez le fichier de configuration
et enfin lancer l'installation en répondant yes

L'installation va se lancer, vous n'avez rien a faire jusqu’à ce qu'il vous demande si vous voullez ou non notifier votre installation a Zimbra, une fois de plus, libre a vous (moi je ne le fais pas).

L'installation se poursuit et se fini. Il vous indique ou il enregistre votre fichier de conf et vous demande de presser entrer pour conclure l'installation. Je vous conseil de rebooter une fois avant de commencer à utiliser Zimbra.

4) Accès au service (pas un brouteur internet) :

Interface d’administration :

adresse : https://ip_du_serveur:7071 (valider le certif)
User : admin
MdP : celui que vous avez saisi lors de l'installations

Interface utilisateur :

adresse : http://ip_du_serveur
User : email, nom de compte, ou alias (avec ou sans le @domain.loc)
MdP : celui définit par l'utilisateur

samedi 15 janvier 2011

Screen

Screen (site du projet) est un multiplexeur de terminaux. Il permet de créer et d'accèder à des sessions sur un hôte distant.
L'avantage par rapport à l'utilisation d'un simple terminal à distance est qu'il s'exécute sur l'hôte et continue donc sa/ses tâche(s) même si le client n'est plus connecté (ou s'il perd temporairement sa connexion).
De plus, avec un seul processus Screen, un client peut créer plusieur fenêtre (numérotées ou nommées) et naviguer entre chacune très simplement, ce qui évite d'avoir plusieur fenêtres coté client (et donc plusieurs connexions).

Principe de fonctionnement

Le fonctionnement de screen est assez simple:
- Un client se connecte à un hôte, et créé un screen
- Une fenêtre (= terminal) est automatiquement générée dans ce screen et le client se retrouve dedans
--> A ce moment, le screen est dit rattaché puisqu'au moins un client l'utilise
- Le client peut créer une ou plusieurs nouvelles fenêtres, naviguer entre elles, lancer des processus dans chacune, etc...
- Le client peut également quitter le screen (sans l'arrêter) ou subir un déconnexion involontaire
--> A ce moment, le screen est dit détaché puisqu'aucun client ne l'utilise
- Le client peut alors revenir sur l'hôte, créer un nouveau screen, ou reprendre (rattacher) le screen précédent

Quelques commandes basiques

Liste les screen en cours

$ screen -ls
__Cette commande affiche également pour chaque screen si celui-ci est rattaché ou détaché

Créer un screen:

$ screen -S {nom_du_screen}

Rattacher un screen

$ screen -r {nom_du_screen}

Forcer le détachement d'un screen

$ screen -d {nom_du_screen}

Récupérer un screen attaché

$ screen -d -r {nom_du_screen}

Raccourcis dans un screen

La plupart des raccourcis se font par la combinaison de touches CTRL+a + {une autre touche}

Créer une nouvelle fenêtre

CTRL+a + c

Renomer la fenêtre courante

CTRL+a + A

Afficher la liste des fenêtres

CTRL+a + "
__Vous pouvez naviguer entre les fenêtre à partir de cet affichage

Changer de fenêtre:

CTRL+a + {numéro_de_la_fenêtre}
__La première fenêtre porte le numéro 0

Switcher entre la fenêtre courante et la précédente affichée:

CTRL+a + CTRL+a

En peu plus loin

Les fenêtres sont paramètrables. Ci-après un exemple de fichier de configuration :
~/.screenrc
# decommenter si t'es en UTF-8
defutf8 on
defbce on
vbell off
startup_message off
defscrollback 10000
altscreen on

hardstatus off
hardstatus alwayslastline
hardstatus string '%{= kG}%H %=%{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{B}%c'

Update (31/12/11) - Quelques ajouts:

Créer une fenêtre dans la fenêtre courante (écran partagé en 2, répétable plusieurs fois):

CTRL+a + S

Se déplacer entre plusieurs fenêtres:

CTRL+a + TAB

Récupérer un bash dans une fenêtre créée:

CTRL+a + c

Autoriser la multisession sur un screen:

CTRL+a + : multiuser on
CTRL+a + : acladd user (pour autoriser le user à rejoindre le screen)

Rejoindre un screen sur un autre session:

screen -x user/

mercredi 5 janvier 2011

Passerelle vers un réseau Tor

Le but de ce billet est de créer une passerelle qui sort directement sur le réseau Tor.
A quoi cela peut bien servir ? Par exemple en changeant la route par défaut d'un client lui permettre d'être anonyme sur la toile (attention aux données sensibles qui transitent dans le réseau Tor tout de même), ou encore fournir une passerelle, potentiellement ouverte, vers internet sans être reconnu comme IP source des paquets sortants.

Tor est un réseau d'ordinateurs (volontairement) zombies qui permet de faire du multi-proxy.

Installer Tor

La première étape est l'installation de Tor sur un serveur:
# apt-get install tor
... et ben voilà, première étape terminée ;)
| Comme toujours, il est possible d'installer Tor à partir de ses sources afin d'avoir la dernière version:
$ wget http://www.torproject.org/dist/tor-0.2.1.28.tar.gz
$ tar xzf tor-0.2.1.28.tar.gz && rm tor-0.2.1.28.tar.gz
$ cd tor-0.2.1.28
$ ./configure
$ make
$ su -c 'make install'

|| Requirements:
# apt-get install build-essential
# apt-get install libevent-dev
# apt-get install libssl-dev

Configuration de Tor

(Rappel: on ne souhaite pas dans ce billet configurer Tor comme relais, mais simplement comme point d'entrée dans le réseau Tor)

Emplacement: /etc/tor/torrc ou /urs/local/etc/tor/torrc

RunAsDaemon 1
# Port et adresse d'écoute du démon Tor(relai)

# ORPort 9001
# ORListenAddress 127.0.0.1
# Port et adresse d'écoute pour les requêtes DNS
DNSPort 53
# Port et adresse d'écoute pour Tor en mode proxy transparent
TransPort 8118
TransListenAddress 0.0.0.0

A présent, vous pouvez lancer Tor:
# invoke-rc.d tor start
ou
# tor

Configuration IP forward

Un simple echo 1 > /proc/sys/net/ipv4/ip_forward suffit, il est également possible d'éditer le fichier /etc/sysctl.conf afin d'activer l'IP forward systématiquement:

net.ipv4.ip_forward=1

Configuration netfilter/iptables

Afin de concentrer tout le trafic entrant vers le proxy transparent local, on configure quelques règles iptables simples:
iptables -F -t nat
iptables -F
iptables -X
## Règles locales
iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-ports 8118
iptables -t nat -A OUTPUT -p udp -m udp --dport 53 -j REDIRECT --to-ports 53
## Règles extérieures
iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-ports 8118
iptables -t nat -A PREROUTING -p udp -m udp --dport 53 -j REDIRECT --to-ports 53

Vous pouvez tester si le proxy fonctionne en local simplement en vous rendant sur www.whatismyip.org (et vérifier que ce n'est pas votre IP) ou:
$ GET whatismyip.org
ou
$ w3m whatismyip.org
Le même test est réalisable à partir d'un client extérieur après lui avoir modifié sa route par défaut.

Configuration annexe

Si vous voulez que l'ensemble du trafic d'un hôte passe systématiquement dans le réseau Tor, il suffit de configurer le serveur DHCP en rajoutant une entrée host. Par exemple pour dhcpd, on peut rajouter l'entrée suivante dans le fichier /etc/dhcp3/dhcpd.conf

host monHote{
fixed-address A.B.C.D;
hardware ethernet XX:XX:XX:XX:XX:XX;
option routers {adresse IP du serveur Tor}
}

Mise à jour: Commande socat:
socat -d -d TCP4-LISTEN:8118,fork,reuseaddr TCP4:<address_ip>:8118

mardi 21 décembre 2010

Exporter une VM depuis ESXi

Bon alors vous aimez, ou pas, VMWare. Une de leurs solutions est gratuite : Le combo ESXi et VShpere.

C'est un peu la misère à activer, il faut chercher un poil, mais ça marche !

Une fois que vous avez tout installé paramétré, fait joujou, configuré, il reste un truc.

Exporter, pour sauver, ou redéployer en plus vite.

Et là c'est le drame.

En effet VSphere ne prends pas en charge l'exportation de la VM.

Du coup, il faut feinter.

Vous avez donc :

Bah vous allez aller télécharger : VMware vCenter Converter Standalone

Et oui, il faut ruser un peu.

Normalement le tout est gratuit.

Donc il faut ouvrir le vCenter Converter .

Cliquer sur Convert machine et suivre les étapes :

  • Sélectionner VMware Infrastructure virtual machine
  • Rentrer l'IP de la machine Hôte
  • Le login qui vas bien (toujours de l'hôte)
  • Le pass associé
  • Et cliquer sur suivant.
  • On sélectionne la VM qui est ETEINTE ! (sinon ça marche moins bien bizarrement).
  • On clique sur next

Allez courage ! Ensuite virtual appliance on met un petit lama en nom Et si on es flemmard on met le tout en OVA, c'est moins crade ca ne fait qu'un fichier.

Ensuite le petit panneau qui sert a éditer la bécane si besoin.

Sinon il vous reste a faire un bon café, ou appeler votre grand mère.

Après un bon film, c'est fini et ça marche.

Si vous n'avez pas aimé, deux solutions : Achetez les versions payantes de Vshepre et de VMware.

Ou passez sur citrix.

mardi 14 décembre 2010

John the ripper en multicore

John The Ripper fait parti des meilleurs crackers de mot de passe, de part sa puissance et sa connaissance de nombreux algorithmes. Cependant, sa version officielle ne permet pas son exécution sur plusieurs core. Heureusement, une implémentation de JTR utilisant OpenMPI existe pour palier à ce problème.

Lire la suite...

lundi 13 décembre 2010

Lighttp : serveur Web

Lighttpd est un serveur web pouvant venir en remplacement d'un apache, en être un frontale ou un backend. L'avantage par rapport à son ancêtre est qu'il est plus légers, moins passoire et relativement plus rapide. Pour référence en production, on peu citer Youtube, wikipedia ...

1) Installation

# sudo aptitude install lighttpd
# sudo /etc/init.d/lighttpd start

  • rien de plus :)
2) PHP

De base le php n'est pas présent, mais s'ajoute sous forme de plugin
# sudo aptitude install php5-cgi

Activer le module
# sudo lighty-enable-mod fastcgi
# sudo /etc/init.d/lighttpd force-reload

3) Mysql

# sudo aptitude install mysql-client mysql-server

  • Suite à cela, il vous sera demandé de configurer mysql avec le login, mdp et autre. Pas bien compliquer et pas l'objet de ce billet.

On active Mysql dans Lightty
# sudo lighty-enable-mod userdir
# sudo /etc/init.d/mysql start // normalement pas utile
# sudo /etc/init.d/lighttpd force-reload

4) PHPmyAdmin (optionnel)

Dans le cas ou vous souhaiteriez pouvoir gerer votre serveur Mysql via une interface graphique.
# sudo aptitude install phpmyadmin
# sudo /etc/init.d/lighttpd force-reload

5) SSL

Pour avoir le HTTPS sur votre serveur
# sudo aptitude install openssl ssl-cert

Création du cerificat
# sudo make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /chemin_de_mon_certificat/mon_certificat.pem

  • dans le cas ou ça ne fonctionnerais pas :

# cd /etc/lighttpd
# openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout mon_certificat.pem -out mon_certificat.pem

Editer le fichier de configuration (/etc/lighttpd/lighttpd.conf) pour la prise en charge
$SERVER"socket" == ":443" {
ssl.engine = "enable"
ssl.pemfile = "/chemin_de_mon_certificat/mon_certificat.pem"
}

Redemarer lightty pour la prise en charge
# sudo /etc/init.d/lighttpd restart

6) Configuration des hosts

Ce n'est qu'un configuration rapide et fonctionnel. Toutefois il existe tout une syntaxe pour la définition des fichiers Hosts sur le site de lighttpd
Se placer dans le dossier des hosts :
#cd /etc/lighttpd/conf-enabled/

Créer son fichier hosts et l'éditer :
# sudo vi mon_fichier.conf

Y ajouter :
$HTTP"host" == "www.exemple.org" {
server.document-root = "/chemin/de/mon/site/"
server.errorlog = "/var/log/mon_log_erreur"
accesslog.filename = "/var/log/mon_log_accès"
}

Activer l'host et le faire prendre en compte
# sudo lighty-enable-mod mon_fichier.conf
# sudo /etc/init.d/lighttpd force-reload

Il est intéressant de faire un .conf par site(host) présent sur le site.


Partage avec samba

Configuration du partage de fichier avec Samba

  • le paquet samba doit être installé

# sudo aptitude install samba

  • toutes les configurations se font dans le fichier smb.conf (en faire une copie de sauvegarde au préalable)
1) Accès libre

Dans ce cas, le partage est accessible à toutes personnes connaissant le chemin. La particularité est que les accès se feront avec l'identité d'un utilisateur défini et ayant les droits sur le partage. Il est possible d'utiliser un utilisateur de la machine ou un utilisateur de crée spécialement (cf : 2.a )

a) Configuration

#======================= Global Settings =======================

[global]

       server string = %h server (Samba, Ubuntu)
       security = SHARE
       syslog = 0
       dns proxy = No
       guest account = utilisateur_par_defaut (ex: root, toto, sambauser ...)
       socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

#======================= Share Definitions =======================

[nom_du_partage]

       comment = commentaire sur le partage
       path =  chemin_du_partage
       public = yes
       guest ok = yes
       read only = no
       create mask = droit_en_création (ex: 0660)
       directory mask = droit_sur_le_répertoire (ex: 0770)
2) Accès Contrôlés

a) Les utilisateurs

Pour un peu plus de sécurité, nous pouvons demander à ce que toutes personnes voulant se connecter au partage soit identifié. Pour cela il y a deux possibilités:

  • Un utilisateur Samba (qui à juste le droit d'accès au(x) partage(s) )

Création de l'utilisateur :

sudo useradd -s /bin/false -d /dev/null -g guest nom_utilisateur

-s /bin/false interdit l’utilisation d'un Shell, -d /dev/null redirige le home vers le néant intersidéral et -g guest le groupe qui accueil les utilisateurs invités (à créer au besoin)

  • Etre un utilisateur du système (qui a le droit de se connecter sur la machine pour avoir un Shell)

Pas besoin de le crée, il exite déjà :)

  • Dans les deux cas il faut définir un mot de passe spécifique à Samba pour les utilisateurs :

sudo smbpasswd -a nom_utilisateur

b) Configuration

#======================= Global Settings =======================

[global]

  workgroup = WORKGROUP
  server string = %h server (Samba)
  dns proxy = no


#### Debugging/Accounting ####

  log file = /var/log/samba/log.%m
  max log size = 1000
  syslog = 0
  panic action = /usr/share/samba/panic-action %d


####### Authentication #######

  encrypt passwords = true
  passdb backend = tdbsam
  obey pam restrictions = yes
  unix password sync = yes
  passwd program = /usr/bin/passwd %u
  passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
  pam password change = yes
  map to guest = bad user


########## Domains ###########

  usershare allow guests = yes

#======================= Share Definitions =======================

[nom_du_partage]

       comment = commentaire sur le partage
       path = chemin_du_partage
       create mask = droit_en_creation (ex: 0660)
       directory mask = droit_sur_le_repertoire (ex: 0770)
       read only = No
       security = share
3) Montage en lecteur windows

Pour monter automatiquement le partage dans windows, il est possible d'ajouter dans le dossier "Démarrage" du menu démarer un batch comprenant la ligne suivant :
net use z: \\chemin_du_partage /user:login mot_de_passe

vendredi 10 décembre 2010

Installation de Kerrighed sous Debian

Installation de Kerrighed 2.4.4 sur un noyau Linux 2.6.26 (version de Debian Lenny)

  • Installer GCC en version 3.4 de préférence, mais ça fonctionne aussi avec la 4.3
  • Installer make et lsb-release
  • Compiler et installer Kerrighed avec la procédure classique :

./configure
make
make install

  • A la fin de la compilation, faire un "ldconfig"
  • Éditer le menu.lst du Grub pour y ajouter le noyau de Kerrighed "linux-image-2.6.20-krg". Au démarrage du noyau, la détection automatique des paramètres du noeud ne semble pas fonctionner. Il faut alors les forcer en ajoutant, toujours dans le menu.lst, les paramètres "session_id" et "node_id".
 title           Debian GNU/Linux, kernel 2.6.20-krg 
 root            (hd0,0) 
 kernel          /boot/vmlinuz-2.6.20-krg root=/dev/sda1 ro session_id=1 node_id=1 
  • Créer le répertoire commun à tous les nœuds :

mkdir /config
Et ajouter le montage au fstab :

configfs /config configfs defaults 0 0
  • Des problèmes de réseau peuvent apparaître si Kerrighed est installé sur une machine virtuelle.

- Sous VirtualBox renommer eth0 en eth1 dans /etc/network/interfaces
- Sous VMware, installer les vmware tools pour avoir le pilote de la carte réseau

Installation de Kerrighed 3.0.0 sur un noyau Linux 2.6.32-amd64 (version 64 bits de Debian Squeeze)

  • Après l'installation, penser à effectuer un "update-grub2" pour pouvoir démarrer sur le noyau Kerrighed

VLC derrière un proxy

Si vous aussi vous voulez écouter une webradio dans votre entreprise sur votre lecteur favoris (et non un webplayer pourrave), il est possible d'ajouter un proxy dans VLC.

  • Sous Windows (testé et approuvé):

1. Click droit sur l'icône "VLC media player"
2. Propriétés
3. Rajouter dans la cible (en dehors des " ")

     --http-proxy=my.proxy.com:8080
  • Sous Linux (à tester):

vlc --http-proxy=monproxyenmousse:1337

Après, il faut aussi une webradio fairplay qui diffuse sur un port non bloqué

mardi 7 décembre 2010

Subsonic : serveur de Streaming audio

1) Installer Java

# sudo apt-get install openjdk-6-jre

2)Télécharger le paquet

# sudo wget http://downloads.sourceforge.net/project/subsonic/subsonic/4.2/subsonic-4.2.deb

3) Installer le paquet

# sudo dpkg -i subsonic-x.x.deb

4) Installation des transcoders

# sudo aptitude install lame flac faad vorbis-tools ffmpeg

5) Configuration

# sudo vi /etc/default/subsonic
# sudo service subsonic restart

6) Accès

http://adresse_ip:4040

7) Voir les logs

# sudo tail -100f /var/subsonic

- page 3 de 4 -