Gérer son PRA à la maison, comme les pros

Dans l’idée d’appliquer des solutions professionnelles aux particuliers, ou, formulé autrement, dans l’idée de professionnaliser mon “home network”, j’ai décidé de mettre en place un “backup” de mes données prenant en compte les intempéries (incendie, tremblement de terre, pluie de sauterelles géantes) et les vols. Il ne vous a pas échappé, en passant, que je suis un brin paranoïaque. Il parait que cela va de pair avec la sécurité.

Donc l’idée est de mettre en place une sauvegarde sécurisée de mes données dans un endroit de confiance suffisamment éloigné de chez moi pour les raisons citées plus haut.

Plusieurs options s’offrent à moi:

• soit je m’offre un service de type “cloud”
• soit je gère moi-même la sauvegarde

Les inconvénients de la première solution, l’achat d’un service de sauvegarde sur internet, sont les suivants:

• il est difficile de savoir réellement où sont archivées les données (dans quel pays ,dans quelles conditions de sécurité,…)
• il est aussi difficile de connaitre la politique de sécurité en ce qui concerne par exemple la suppression des données: (sont-elles réellement supprimées?) et la suppression du compte
• et finalement les meilleurs services sont assez chers quand on les compare aux avantages de la deuxième solution

L’avantage de la deuxième solution est, hormis un prix d’entrée plus important (surtout si vous partez de “0” en terme de matériel), est le contrôle total de l’hébergement et de la sécurité. Et cette solution peut être rentabilisée sur quelques années!

Quelles sont les pré-requis pour la mettre en œuvre?

• posséder deux NAS (un pour la maison et un pour le site de sauvegarde)
• disposer de la fonctionnalité “rsync” ou équivalente sur chacun des NAS
• et avoir un ami (ça c’est pas simple), de confiance (ça c’est encore plus dur) et habitant à une distance raisonnable de la maison ( ça c’est quasi impossible, mais j’ai quand même fini par en trouver un, merci “Glando”)

Donc, l’idée consiste comme vous l’avez compris à configurer un NAS (Network Access Server) en “maitre” pilotant la sauvegarde (compressée et chiffrée, la sécurité c’est important), et l’autre NAS en esclave (capable d’accepter la sauvegarde). Puis de définir une fréquence de sauvegarde en fonction de la criticité de vos données.

Voici comment le NAS '”esclave” est configuré (au fait j’utilise des NAS Synology, du matériel quasi pro à mon avis):

Dans “Panneau de configuration / Sauvegarde réseau”:

Et voilà la configuration du NAS “maitre”:

Dans “Sauvegarder et restaurer”:

Dans “Obtenir des informations”:

Bien entendu vous devez configurer les firewalls (local et distant). La configuration choisie est la suivante (elle peut certainement être optimisée):

La bonne nouvelle, à part que cela marche bien entendu, est que votre bande passante internet n’est quasiment pas affectée. Oui, oui, vous pouvez continuer à jouer à BF3 en réseau!

Remarque: en fonction de la quantité de données que vous souhaitez sauvegarder, le premier “backup” peut prendre longtemps, très longtemps! Mais on s’en fiche, c’est en “background”, et sans réel impact sur votre bande passante (ca je l’ai déjà dit!), et cela même si vous avez pris la précaution au préalable, de synchroniser vos NAS sur votre réseau local.

Note: vos commentaires permettant pour améliorer la solution sont les bienvenus.

Merci à “Uzy” pour son précieux retour sur la faisabilité.

Passe-moi le “hash”, s’il te plaît…

Dans la série, “Vidéos avec Metasploit”, en voici une sur l’exploitation d‘une faille '”Microsoft SQL Server” et d’une faille SMB.

Comme toujours l’objectif est d’obtenir un “shell” sur la machine de la victime.

La particularité de cette vidéo, au-delà de l’exploitation de la faille “Microsoft SQL Server” liée à une mauvaise configuration de la base de données, est  de réaliser un “pass the hash”. Mais qu’est-ce donc qu’un “pass the hash”?

Une fois que l’on a “dumper”, le contenu du fichiers des mots de passe de Windows, une alternative se présente:

• soit on “craque” le mot de passe de l’administrateur, à l’ancienne, avec un outil comme “john the ripper”. Mais cela demande généralement un peu de temps, proportionnel à la longueur du mot de passe
• soit on utilise directement le hash pour s’authentifier sur la machine cible en tant qu’administrateur: c’est la technique du “pass the hash”. Solution qui, cela va sans dire, est beaucoup plus rapide

C’est cette deuxième approche que l’on utilise dans cette vidéo.

Mais je vous laisse juger par vous même.

Dans la seconde partie de la vidéo, on s’attarde sur l’exploitation du “shell” que l’on vient d’obtenir en tant qu’administrateur sur la machine cible (cette partie est assez habituelle).

Remarque: dans cette exemple la longueur du mot de passe est de 7 caractères. Un de mes camarades, merci “Uzy”, m’a remonté un problème avec des mots de passe de plus de 7 caractères. Vos commentaires sont donc les bienvenus.

Hydra, pour auditer vos services “web”

Si comme moi vous souhaitez “auditer” la sécurité des services que vous déployez sur Internet alors Hydra doit faire partie de votre boite à outils.

Hydra permet de tester le niveau de sécurité des noms d’utilisateurs et des mots de passe associés à vos services.

Pour tester votre service SSH, vous pouvez soit utiliser la version graphique de Hydra (appelé hydra-gtk)

ou bien, pour les puristes, saisir la commande suivante

> hydra –s port_service –L /pentest/logins.txt –P /pentest/passwords.txt –t 16 –f www.votreurl.fr ssh

où:

• -s est le port du service
• -L est le fichier des noms d’utilisateurs
• -P est le fichier des mots de passe
• -t est le nombre de tâches en parallèle
• -f permet d’arrêter en cas de succès
• www.votreurl.fr est l’URL du serveur
• ssh est le protocole

Pour tester l’authentification de votre site web, vous pouvez utiliser la commande:

> hydra -L /pentest/logins.txt -P /pentest/passwords.txt -t 16 -f -m /repertoire www.votreurl.fr http-get

où:

• -L est le fichier des noms d’utilisateurs
• -P est le fichier des mots de passe
• -t est le nombre de tâches en parallèle
• -f permet d’arrêter en cas de succès
• -m est le répertoire à tester
• www.votreurl.fr est l’URL du serveur
• http-get est le protocole

Bon audit!

Source: Téléchargement d’Hydra disponible sur http://www.thc.org/thc-hydra/

Un fichier peut en cacher un autre

Il y a quelques jours je suis tombé sur une fonctionnalité de Windows pour le moins déconcertante.

Figurez-vous qu’il est possible de cacher un fichier derrière un autre fichier! On peut par exemple cacher un exécutable derrière un fichier texte existant déjà. Et seul celui qui a caché le fichier sait le retrouver.

Ce type de fonctionnalité pourrait être très utile pour le “visiteur” d’une machine qui souhaite y laisser quelques données car il a bien envie d’y revenir plus tard pour continuer son travail!

Quelques éclaircissements s’imposent!

Cette astuce est permise par l’utilisation de ADS (Alternate Data Stream). ADS est une fonctionnalité native de Windows NTFS permettant la compatibilité avec le système de fichiers d’Apple.

1ère étape:sur un Windows 7, cachons un fichier texte derrière un autre fichier texte
C:\Test>type wanttohide.txt > normal.txt:hidden.txt
C:\Test>del wanttohide.txt
C:\Test>notepad.exe normal.txt:hidden.txt

Bien que supprimé, le fichier “wanttohide.txt” s’ouvre.

2ème étape: sur un Windows XP SP3, cachons un fichier “exécutable” derrière un fichier texte
C:\Test>type notepad.exe > exec.txt:hidden.exe
C:\Test>del notepad.exe
C:\Test>start C:\Test\exec.txt:hidden.exe

Bien que supprimé, l’exécutable “notepad.exe” s'ouvre.

Cependant il faut noter que n’importe quel “kit de forensics” permet de vérifier la présence d’ADS.

Source: livre “CEH” de Matt Walker aux éditions Mc Graw Hill