X-Space

Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - Admin Système

Fil des billets - Fil des commentaires

lundi, février 1 2010

Comment migrer un dépot subversion dans un autre dépot existant ?

Jusqu'à récemment à chaque fois que j'avais besoin de versionner un projet, je créais un nouveau dépôt subversion ce qui revenait à faire :

  • Via SSH : svnadmin create /some/path/
  • Création d'un VirtualHost Apache (avec le htaccess qui va bien)
  • Installation d'un WebSVN

Tout ca pour au final me retrouver avec une dizaine de dépôts (et autant d'URL) ayant chacun moins de 100 commits. J'ai donc décidé de fusionner tous ca sous une URL unique avec certificat TLS par dessus.

Deux hics :

  • Comment importer mes dépôts dans le dépôt existant ?
  • Comment définir une convention de nommage des dépôts ?

Pour la deuxième question ce fut assez simple : je me suis basé sur l'arborescence DNS inversée (ca tombe bien la majorité de mes projets ont une URL) :

Exemple : Si ce blog était versionné il le serait sous la forme net/x-space/www/ avec dans ce dossier les traditionnels trunk, branches et tags.

Pour la première question : et bien les développeurs de subversion ont pensé à tout.

svnadmin dump /path/to/the/old/repository/ > net.x-space.www.dump

Puis

svnadmin load --parent-dir net/x-space/www/ /path/to/the/new/repository/ < net.x-space.www.dump

Pour en savoir plus :

samedi, novembre 15 2008

Déconnexion d'un spammeur

Le Washington Post (Via ASI) nous a appris cette semaine que l'un des plus gros spammeurs mondiaux, situé aux États Unis, a été déconnecté du réseau.

L'effet de cette coupure est impressionnant. Je vous laisse juger par vous même sur les statistiques de mon seul serveur :

Note : Ce graphique a été produit grâce aux données fournies par le script log-report.sh de la version patché de Qmail Scanner et mise en forme avec Excel 2007.

lundi, août 11 2008

Modifier les chmods à la volée.

Quand j'étais jeune ( comprendre il y a deux ans ), j'avais tendance à ne pas me casser les pieds au niveau des chmods et faire

chmod -R 777 mondossier

C'est pas propre, pas logique ( un fichier ne doit pas pouvoir être exécuter, potentiellement dangereux etc... Ayant vieilli, et commençant la migration du serveur actuel vers le nouveau je suis tombé sur un problème de chmod incohérent et j'ai donc du reconstruire le tout. Plutôt que de faire ça à la main ou en mode récursif ( -R ), j'ai développé un petit script pour faire les choses proprement : (télécharger)

Utilisation

./chmodalavolee.sh mondossier

Grossièrement le script fait :

Pour chaque fichier dans mondossier : chmod 644 (lecture pour tous et seulement écriture pour le propriétaire).

Pour chaque dossier : chmod 755 (lecture et exécution - obligatoire pour rentrer dans un dossier - pour tous, écriture en plus pour le propriétaire). Exécuter le script dans ce dossier.

Seul problème ce script ne donne pas les droits d'exécution sur le fichier. Ce qui peut être problématique si on fait un 777 sur un dossier contenant des exécutables.

Un collègue, qui a fait cette erreur malencontreuse, m'a donc posé la question : y a il des fichiers exécutables dans /var ?

Ma réponse est dans le fichier var-executable-files que j'ai généré avec le script search-executable.sh.

mardi, août 5 2008

Comment récupérer un mot de passe root sans être root ?

Récemment j'ai perdu le mot de passe root d'un serveur que j'administre (ok je suis un boulet).

Alors comment restaurer un mot de passe root quand on a perdu ce mot de passe ?

Première solution : linux single

Ce mode permet de démarrer le système en root, ne reste qu'à modifier le mot de passe puis à rebooter et c'est bon.
Sauf que ça implique une intervention manuelle sur le serveur et :

  • le datacenter est à plus de 350 km de chez moi ;
  • je n'avais pas envie de téléphoner aux responsables du DC pour ce genre de bêtises.

Deuxième piste : vmsplice local root exploit

Cette faille permettait à n'importe quel utilisateur d'exécuter des commandes root.
Cette faille a été corrigée dans la version 2.6.24. Manque de bol j'avais déjà mis à jour le serveur lors de la publication de la faille.
L'exploit n'a donc rien donné.

Troisième piste :

Heu la j'ai un peu séché pendant 1 ou 2 heures, en réfléchissant autour de la question : comment exécuter un script root sans être root ?
Impossible théoriquement.

Jusqu'à ce que pense à regarder les crons, un des scripts du site effectue une sauvegarde quotidienne de la base de données.
Ce script s'exécute en cron mais peut aussi être exécuter à la main dans le site via un exec.Apache en est le possesseur. Ne reste plus qu'a le modifier sauf que je ne suis pas Apache et que je n'ai aucun droit sur ce fichier même pas en lecture.
Et si je me faisais passer pour Apache ?
La version beta du site étant accessible pour moi, j'ai créé une page php afin qu'elle modifie le script de backup :

#!/bin/sh
echo root:<motdepasse> | chpasswd

J'exécute le script dans mon navigateur, comme c'est apache qui exécute la page donc j'ai le droit d'édition sur le script de backup. Ne restait plus qu'a attendre que le cron passe. Et hop le tour est joué.

Joli faille de sécurité ?

Plus ou moins:

  • Je possède le seul compte utilisateur accessible via SSH
  • fail2ban fait le ménage sur les attaques des robots.

Mais j'ai un script qui s'exécute en root qui est modifiable par un utilisateur quelconque ce qui relève donc d'une faille possible. J'ai donc retiré tout droit d'écriture sur le fichier.

samedi, avril 19 2008

Quelques heures dans la peau de TitaX, suite et fin

Avec 6 mois de retard, voici la suite et la fin de mes aventures (partie 1, partie 2).

Lors de mon dernier billet, de nombreuses questions restaient en suspend : problème matériel (mon opinion) ou problème d'OS (Dell).

Comme je le prévoyais le serveur est retombé mi aout. L'OS est donc clairement hors de causes, mais le technicien Dell (toujours le même) ne voulait toujours rien savoir.

J'ai lancé des stress tests (thrash, bonnie++) sur les disques durs sans résultats.

J'ai alors soumis le problème à mes colistiers de SOS-Admin, qui flairaient eux aussi le problème hardware. Du fait de l'absence de syslog, Stephane B. m'a suggéré d'externaliser les logs.

Externaliser les logs, mais qu'est ce donc ?

Et bien c'est tout simple, les logs sous linux sont gérer par un petit démon qui s'appelle syslogd. Ce petit démon possède une fonctionnalité plutôt intéressante : il permet d'envoyer les logs d'une machine sur une autre machine (externaliser !). Plutôt pratique lorsque la machine à des problèmes de disques durs et donc que rien ne s'écrit dans les fichiers logs.

Voyons maintenant comment configurer le bouzin.

Coté émetteur :

C'est assez simple : il suffit de configurer syslogd afin de lui dire quel type de log on veut envoyer sur le serveur distant. Dans mon cas, on log tout.

$ cat /etc/syslog.conf | grep "x-space"
*.*                                                     @x-space.net

Coté destinataire c'est un peu plus compliqué :

Tout d'abord, il faut demander au démon d'écouter sur le réseau (désactivé par défaut):

# tail -n1 /etc/default/syslogd
SYSLOGD="-r"

Puis on ouvre la parefeu en UDP sur le port de syslog (voir /etc/services):

iptables -A INPUT -s IP_EMETTEUR -p udp --dport 514  -j ACCEPT

Ne reste plus qu'a redémarrer les démons de chaque coté.

Et la magie :

Aug 28 19:02:47 ******* kernel: sd 0:2:0:0: SCSI error: return code = 0x00040000
Aug 28 19:02:47 ******* kernel: end_request: I/O error, dev sda, sector 242365
Aug 28 19:02:47 ******* kernel: sd 0:2:0:0: SCSI error: return code = 0x00040000
Aug 28 19:02:47 ******* kernel: end_request: I/O error, dev sda, sector 242381
Aug 28 19:02:47 ******* kernel: lost page write due to I/O error on dm-0
Aug 28 19:03:18 ******* kernel: sd 0:2:0:0: SCSI error: return code = 0x00040000
Aug 28 19:03:18 ******* kernel: end_request: I/O error, dev sda, sector 94319189
Aug 28 19:03:18 ******* kernel: lost page write due to I/O error on dm-0

Epilogue

Le technicien Dell (toujours le même) a alors voulu exclure un dysfonctionnement lié au disque 2 vu que c'est que lui qui remontait des erreurs donc il m'a demandé de faire fonctionner le RAID en mode dégradé (on retire un disque). Ça a marché jusqu'à que le serveur retombe "définitivement" : le raid s'est effondré et n'a pas pu se remonter sur deux disques. J'ai du donc gueuler la sérieusement sur un autre technicien Dell qui a bougé cette fois et a fait changer le contrôleur RAID rapidement (J+1). Depuis le serveur fonctionne très bien.

Backup FTP

Depuis mercredi et comme chaque année, OVH vient de passer sa gamme de serveurs dédiés en reloaded. En gros, plus de services pour le meme prix.

Depuis mercredi, j'ai donc accès au service gratuit de sauvegarde par ftp. Reste à trouver un moyen d'automatiser la sauvegarde et donc plutôt que réinventer la roue, j'ai trouvé le script, bien documenté d'ailleurs, de DanSteph. Seul petit soucis, il n'existe pas de package natif ncftpput sous Debian Etch. C'est la que je me suis rappelé de la commande dont m'avais parlé TitaX dernièrement et que j'avais déja utilisé : lftp.

Et hop en deux temps, trois mouvements c'était corrigé :

lftp -u $USER,$PASS -e "put $TEMPDIR$FILENAME.gz -v; quit" $SERVER

dimanche, février 24 2008

Ma première DDOS

Aujourd'hui j'ai vécu ma première attaque par déni de service.

Statistiques Ping pour 91.121.29.90:
Paquets : envoyés = 92, reçus = 49, perdus = 43 (perte 46%),
Durée approximative des boucles en millisecondes :
Minimum = 128ms, Maximum = 244ms, Moyenne = 177ms

Chapeau bas au support d'OVH qui à 12h m'envoie un mail comme quoi mon serveur ne ping plus, puis annule l'intervention 10 minutes après parce que ca reping. Je les contacte à 15h car mon serveur est inaccessible, en leur demandant s'il y avait une attaque: réponse à 19h: ca ping... Aucunes informations durant l'évènement.

dimanche, juillet 29 2007

Quelques heures dans la peau de TitaX, la suite

Suite de mes aventures.

Le serveur est retombé le 19 juillet. Donc la mise à jour du controleur RAID et des disque dur n'a rien changé.

Recontact avec Dell.

On a d'abord tenté d'installer l'utilitaire DSET (Utilitaire de support pour systèmes Dell) mais comme c'est du Debian, ca passe pas ( Dell supporte uniquement les produits RedHat ).

Rendez vous fut pris pour utiliser un LiveCD ( basé sur REHL 4.4 ) afin d'accéder aux journaux systèmes.

Les logs ne contenaient rien de vraiment intéressants. M'enfin il faut quand même remarquer que la machine est tombé trois fois:

  1. Le 27 juin 2007 ( date du constat, cela peut être la veille )
  2. Le 03 juillet 2007
  3. Le 19 juillet 2007 à 19h30

Et que à des dates similaires, il s'est produit la perte de l'une des alimentations redondantes:

Severity : Critical
Date and Time : Tue Jun 26 17:21:50 2007
Description : PS 1 Status: power supply sensor for PS 1, failure was asserted

Severity : Critical
Date and Time : Tue Jun 26 17:21:51 2007
Description : System Board PS Redundancy: PS redundancy sensor for System Board, redundancy lost

Severity : Critical
Date and Time : Tue Jun 26 17:21:51 2007
Description : PS 1 Status: power supply sensor for PS 1, input lost was asserted

  1. Le 26 juillet 2007 - 17h21
  2. Le 19 juillet 2007 - 18h17
Je trouve la coïncidence troublante. Tellement troublante que j'ai envie de faire le test à mon retour de vacances si la machine n'est pas retombé d'ici la.

Quel peut être le lien entre un disque dur en read-only et un problème électrique?
  • Surtension ?
  • Mauvaise isolation électrique?
  • Court-circuit ?

Il reste que Dell pour l'instant ne croit pas au problème hardware mais à un problème de l'OS, on est donc passé sous CentOS 5 ( non supporté par Dell mais c'est du REHL à 99.999% ).




mardi, juillet 10 2007

Quelques outils pour surveiller un serveur

iftop


Cet outil permet de surveiller le trafic circulant sur une interface à la manière d'un top. Ca m'a été trèsutile pour identifier la provenance d'un trafic anormal sur ce serveur le matin: Googlebot !

logwatch

Comme son nom l'indique, ce programme analyse les fichiers de logs et génère un mail informatif tous les matins.
  • Echec de connexion ssh
  • Echec de connexion ftp
  • Connexion imap
  • Occupation disque dur
  • Résumé du trafic Apache2, liste des erreurs 404
  • ...
Bref indispensable

Installation ?

aptitude install logwatch

aptitude install iftop

Et hop ca roule.

jeudi, juillet 5 2007

Quelques heures dans la peau de TitaX

Je suis actuellement en stage de 2ième année et dans le cadre de ce stage, avec un collègue, je développe un site web / espace collaboratif mais dois aussi installer et configurer le serveur web qui accueillera le site. La machine est un PowerEdge 2950 ( Père Noël si tu passes dans le coin ) sur lequel on a installé Debian Etch ( oui je sais j'ai toujours pas publié mes notes d'installation de ce serveur ). Sauf que, gros problème, le système de fichier se met de temps en temps en lecture seule.

Lire la suite...

samedi, mai 12 2007

fail2ban

En étudiant les logs du serveur suite à une variation anormale de la RAM utilisée, je viens de m'apercevoir que le serveur subissait des attaques par force brute.

Petit exemple:

May 12 07:31:01 nsXXXX sshd[30255]: Illegal user bnc from 66.XXXXXX
May 12 07:31:01 nsXXXX sshd[30255]: Address 66.XXXXXX maps to mail.XXX.com, but this does not map back to the address - POSSIBLE BREAKIN AT TEMPT!
May 12 07:31:01 nsXXXX sshd[30255]: error: Could not get shadow information for NOUSER
May 12 07:31:01 nsXXXX sshd[30255]: Failed password for illegal user bnc from 66.XXXXXX port 41663 ssh2

Premier réflexe: bannir l'adresse IP, iptables est notre ami!

iptables -A INPUT -s 66.XXX-j DROP

Après une étude plus attentive, je me suis aperçu que ce n'était pas la première fois et pas uniquement sur cette IP. Je me suis souvenu d'un petit programme qui surveillait les logs d'authentification et procédait à un ban temporaire de l'adresse IP le cas échéant: fail2ban.

aptitude install fail2ban

J'ai aussi configuré la surveillance sur Apache, proftpd.

Lien Externe

Fail2ban contre l'attaque par brute force

jeudi, mai 10 2007

Organisation FileSystem: FTP, Apache

Je vous parlais précédemment de mon projet de réinstallation du serveur qui héberge X-Space pour passer à Debian 4 ( Etch ). Avant de pratiquer cette installation, je me pose la question de l'organisation des fichiers.

La problématique est de gérer de multiples domaines, de multiples utilisateurs et une architecture claire.

Par défaut, Apache est configuré pour pointer vers /var/www sur la partition / donc. Or sur le serveur la partition / est de petite taille. On va donc utiliser /home qui est une partition à part.

Plusieurs sites, plusieurs domaines, j'inclinerais donc à construire comme ca:

  • /home/livebox-script.com/
  • /home/cyber-addict.fr/
  • /home/x-space.net/
  • /home/temp/
  • ...

Plusieurs utilisateurs, avec leur propre HomeDirectory.

  • /home/ED/
  • /home/TitaX/
  • ...

Un site peut être géré par plusieurs utilisateurs, cet utilisateur peut avoir son propre ftp, accessible par VirtualHost.

Pour l'instant la solution que je retiens est de monter l'arborescence souhaité dans le dossier de l'utilisateur concerné avec la commande mount.

mount --bind /home/x-space.net/ /home/ED/x-space.net/

Ce qui nous donne:

  • /home/ED/x-space.net/ -> http://www.x-space.net
  • /home/ED/temp/ -> http://temp.x-space.net
  • /home/ED/www/ -> http://ed.x-space.net

Se pose maintenant, la gestion des droits et des utilisateurs, quel serveur FTP a utilisé ? pure-ftpd ou proftd ? Comment laisser la possibilité à plusieurs utilisateurs d'accéder et de modifier le même contenu.

Ce sera l'objectif d'un autre billet, mais je suis ouvert à toutes vos propositions, idées. N'hésitez pas non plus à nous partager votre architecture en commentaires ou sur votre blog. ( hein TitaX )