Korben - Site d'actualité geek et tech



  • DANS TON CHAT (BASHFR)

    G33ky: Pff c'est n'importe quoi de dire que GTA IV est la cause d'un minot qui brule des bagnoles parce que il le dit !
    G33ky: Moi depuis que je joue a Mario bros, je saute sur des tortues, je balance leurs carapaces sur les gens, et je casse toutes les briques que je trouve pour trouver un champignon qui me fera grandir.
    Dayvaiday: Moi depuis que je joue a Kirby j'aspire tout les objets que je trouve pour en prendre l'apparence...
    Zery: Ah bah ça explique pourquoi t'as une tête de bite!

    -- http://danstonchat.com/8168.html
  • RSS Emplois sécurité

  • Site hébergé par
    Agarik Sponsor Korben
  • Selection de contenus

  • Les articles dans "Linux"

    Dply – Un VPS gratuit pour 2h

    5

    Voici un service original qui m'a été remonté par Guillaume. Cela s'appelle Dply et ça permet en quelques secondes et gratuitement, d'avoir un serveur virtuel (VPS) pour tester votre code ou vos applications.

    Les VPS ont la config suivante : 1 CPU, 512 MB de RAM et 20 GB de SSD. Pour avoir votre instance, il suffit de se connecter avec son compte Github et d'utiliser la clé SSH de celui-ci.

    Niveau OS, vous pouvez avoir sur le serveur, les distribs suivantes :

    • CentOS 6
    • CentOS 7
    • Debian 7
    • Debian 8
    • Fedora 23
    • Fedora 24
    • Ubuntu 14.04
    • Ubuntu 16.04
    • Mumble Voice server sur Ubuntu

    Alors je disais que c'était gratuit, mais pour être plus précis, c'est gratuit pendant 2h. Au-delà, il faudra payer... Mais bon, ça reste raisonnable. Voici les tarifs :

    •  $2 - 2 jours
    •  $3 - 1 semaine
    • $10 - 1 mois
    • $50 - 6 mois

    Cela peut permettre à n'importe qui de tester rapidement un script ou un bout de code, directement sur un serveur, sans avoir à mobiliser des ressources ou à prendre des risques avec un serveur déjà utilisé pour autre chose.

    Bref, à bookmarker pour le jour où vous avez besoin d'un serveur ou d'un peu de ressource.

    A découvrir ici.

    Sauvegardez votre serveur Linux sur Amazon S3 avec Backup Manager

    6

    Dans la vie, y'a 2 choses vraiment importantes.

    • 1/ L'amour
    • 2/ Faire des sauvegardes

    Alors on va voir aujourd'hui comment mettre en place une sauvegarde d'un Linux avec upload vers Amazon S3 (mais vous pourrez aussi faire de l'upload vers FTP ou un autre serveur via SSH).

    Et pour cela, on va utiliser Backup Manager. Le site officiel a disparu, mais les sources sont sur Github et apparemment toujours maintenues. Vous allez voir c'est très simple.

    Placez vous dans votre répertoire home

    cd ~

    Et clonez le dépôt git

    git clone https://github.com/sukria/Backup-Manager.git

    Placez vous dedans

    cd Backup-Manager

    et installez Backup Manager avec la commande (vous devrez peut être utiliser sudo)

    make install

    Copiez le fichier de conf dans /etc/.

    cp /usr/share/backup-manager/backup-manager.conf.tpl /etc/backup-manager.conf

    Puis ouvrez ce fichier.

    nano /etc/backup-manager.conf

    On va regarder ça ensemble et je vais me concentrer uniquement sur les paramètres essentiels. Pour le reste, je vous laisserai vous documenter.

    Dans la section Repository, choisissez le répertoire (BM_REPOSITORY_ROOT) où seront stockés les backups en local. Par défaut c'est /var/archives.

    archives

    Si vous avez de la place sur votre disque à cet endroit, créez un répertoire /var/archives (mkdir /var/archives) et ne touchez pas à ce paramètre.

    Concernant les backups, vous devez aussi préciser le nombre de jours que vous voulez garder (BM_ARCHIVE_TTL). Ici c'est 5 jours, mais en ce qui me concerne, je mets un peu plus, car j'ai de la place sur le disque dur.

    jours

    On va ensuite choisir la méthode de sauvegarde. Vous pouvez faire uniquement un export tarball (archive simple) ou un export tarball incrémentale (archive complète + archives différentielles), un export svn, un export mysql...etc.

    tarball

    Comme vous pouvez le voir, moi j'ai mis pour le paramètre BM_ARCHIVE_METHOD : "tarball-incremental mysql"

    Cela va déclencher un backup incrémental et un backup MySQL. Sachez que même si vous choisissez tarball-incremental, vous devez quand même éditer la section tarball ci-dessous.

    tarboule

    Au niveau de BM_TARBALL_DIRECTORIES, vous devez lister les répertoires que vous souhaitez sauvegarder. En ce qui me concerne, ce sera /etc et /var/www. Mais ça peut aussi être /home/ ...etc

    Un peu plus bas, BM_TARBALL_BLACKLIST concerne les répertoires à exclure du backup. Cela peut être pratique si vous voulez sauvegarder tout votre répertoire /home, mais pas /home/archives qui contient vos backups ou d'autres choses dont vous n'avez pas besoin..

    Enfin, BM_TARBALL_SLICESIZE permet de choisir des tailles max d'archives. Ici ce sera donc des archives de 1GB max à chaque fois.

    Passons ensuite aux spécificités de l'incrémental.

    incre

    BM_TARBALLINC_MASTERDATETYPE vous permet de préciser si vous voulez une archive master par semaine ou par mois. Et ensuite de spécifier la fréquence de celle-ci (BM_TARBALLINC_MASTERDATEVALUE). Donc là, dans mon exemple, le master sera réalisé 1 fois par mois.

    Passons ensuite à la conf MySQL. Ici, c'est du classique... login, mot de passe, port de MySQL...Etc

    mysql

    Petit parenthèse, concernant l'export MySQL, j'ai eu des petites erreurs de type

    errno: 24 - Too many open files

    Dans ce cas, pensez à ajouter le paramètre "open_files_limit = 3000" (je vous laisse choisir le nombre en fonction de vos besoins), dans la config mysqld.cnf et à relance MySQL.

    Voilà, c'est terminé pour cette première partie. On va donc faire un test sans s'occuper de l'upload. Pour cela, mettez "none" dans le paramètre BM_UPLOAD_METHOD.

    export

    Sauvegardez le fichier, et lancez la commande

    backup-manager -v

    Et là, vous verrez si tout se passe bien. Si vous avez des erreurs, il y a des chances que ça concerne MySQL. Pensez à bien lire les logs d'erreur retournés pour comprendre de quoi il s'agit.

    Pour surveiller que le backup est en cours, jetez un oeil dans votre répertoire /var/archives en faisant des "ls -l" à la suite pour voir la taille des fichiers augmenter.

    Bon, ça, c'était le plus long à faire. Maintenant on va balancer tout ça sur Amazon S3. Vous pouvez bien sûr choisir une autre méthode d'upload comme FTP ou transfert via SSH. Et vous pouvez en mettre plusieurs... Par exemple envoyer le backup vers un FTP et vers S3.

    Mettez donc le paramètre BM_UPLOAD_METHOD sur s3

    s3

    Alors concernant S3, il y a besoin de 3 paramètres :

    config

    BM_UPLOAD_S3_DESTINATION c'est ce qu'on appelle le Bucket. Pas besoin de le créer en amont sur Amazon S3. Mettez ce que vous voulez et le script le créera pour vous directement.

    BM_UPLOAD_S3_ACCESS_KEY et BM_UPLOAD_S3_SECRET_KEY, ce sont les identifiants S3 dont vous avez besoin. Pour cela, rendez vous ici sur votre compte S3 :

    Cliquez sur Manage Users

    iam1

    Et ajoutez un nouvel utilisateur

    iam2

    Donnez lui un nom et cochez la case programmatic access.

    iam3

    Si vous n'avez pas encore créé de groupe avec les droits sur la partie S3, faites-le.

    iam4

    Finalisez la création de l'utilisateur

    iam5

    Puis récupérez l'Access Key ID et le Secret Access Key pour les mettre dans le fichier de conf de Backup Manager.

    iam6

    Et voilà... Maintenant y'a plus qu'à retester backup manager pour voir si le bucket est bien créé et si vos fichiers sont bien envoyés vers S3.

    backup-manager -v

    Comme Backup Manager utilise Perl, il est possible que vous ayez une de ce style :

    Net::Amazon::S3 is not available, cannot use S3 service : Can't locate Net/Amazon/S3.pm in @INC (you may need to install the Net::Amazon::S3 module) (@INC contains: /etc$

    BEGIN failed--compilation aborted at (eval 11) line 2.

    The upload transfer "s3" failed.

    Cela veut tout simplement dire que le module perl S3 n'est pas présent sur votre système. Faites donc un

    sudo apt-get install libnet-amazon-s3-perl

    Puis un

    sudo cpan Net::Amazon::S3::Client

    Et voilà ! Recommencez :

    backup-manager -v

    Normalement, si tout se passe bien, vos fichiers seront envoyés vers Amazon S3. Très bien !

    Maintenant on va mettre tout ça dans la crontab pour que Backup Manager se lance tous les jours à minuit.

    Lancez donc la commande

    crontab -e

    Et dedans, mettez

    0 2 * * * backup-manager

    Le 2 veut dire que ça va se lancer tous les jours à 2h du mat. Je ne rentre pas plus dans le détail car cet article est déjà assez long. Si vous voulez mettre autre chose, et que vous ne maitrisez pas la syntaxe cron, allez faire un tour sur ce site.

    Un autre truc qui peut être intéressant aussi, c'est d'utiliser Amazon Glacier, en plus de S3. On peut par exemple directement depuis les paramètres de S3, mettre en place un cycle de vie de nos sauvegardes. Les conserver par exemple 30 jours sur Amazon S3, puis les basculer sur Glacier au bout de 30 jours et les supprimer de S3 au bout de 90. Ainsi, elles seront archivées ad vitam eternam (ou à peu près ) dans Glacier.

    Si ça vous branche, voici comment faire. Placez-vous sur votre Bucket S3 fraichement créé qui contient vos sauvegardes, cliquez sur "Properties", et "Add Rule" dans la section Lifecycle.

    life2

    Choisissez d'appliquer cette future règle à votre Bucket

    life3

    Puis c'est sur cette partie que vous devez régler le cycle de vie de vos backups. Ici, je choisis d'archiver vers glacier au bout de 60 jours et de supprimer mon archive sur S3 au bout de 120 jours.

    glaciermove

    Une fois la règle créée, vous avez alors un résumé ici. Cliquez sur le bouton "Create and Activate rule".

    life6

    Et voilà ! life7

    L'intérêt avec Glacier, c'est que c'est moins cher que S3 pour du stockage à long terme. Par contre, attention, si vous avez besoin de récupérer sur Glacier des archives de moins de 90 jours, vous devrez payer assez cher. Donc autant laisser une petite marge avant la suppression sur S3.

    Ensuite pour voir vos backups Glacier, il vous suffira dans l'interface S3, de cliquer sur le bouton "Show".

    glacier

    Bon, voilà, j'ai fini. Un long tuto mais un tuto indispensable car une fois encore au risque de me répéter, les backups c'est HYPER IMPORTANT.

    Enfin, pour terminer en beauté, pensez à récupérer de temps en temps vos backups et en vérifier le contenu, voire à remonter une base avec et votre site pour voir si tout se déroule bien. C'est tout aussi important !

    Bonne sauvegarde à tous !

    Machines à voter, machines à truquer

    25

    Les machines à voter c'est l'avenir ! Surtout, car ça permet de truquer une élection beaucoup facilement qu'en cachant des bulletins de vote dans ses chaussettes .

    Tenez par exemple, aux États-Unis pour l'élection de Trump, certaines machines utilisées lors de l'élection de Tump, sont des machines à voter de type Sequoia AVC Edge. Elles sont présentes dans 13 états américains. Et c'est intéressant, car les chercheurs en sécurité de Cylance se sont penchés sur celle-là.

    En quelques étapes simples et sans droits particuliers, ils ont été capables de rediriger n'importe quel vote d'un candidat à un autre (genre, vous votez pour Hillary et ça incrémente le score de Trump), de changer le nom des candidats et, simplement en insérant dans la machine une mémoire flash PCMCIA, ils ont pu mettre à jour les données relatives au vote, grâce à un fichier spécialement forgé pour l'occasion et contenant de fausses données de vote.

    Easy peasy quoi.

    Voici la vidéo qui montre tout ça :

    Bref, rien de bien rassurant une fois encore, sur la machine à voter électronique. D'ailleurs, des questions commencent à se poser sur la dernière élection...

    Je suis à fond pour les nouvelles technos et le vote électronique, pourquoi pas, mais avant d'avoir confiance en ce machin, il va falloir que les mecs qui les fabrique aient quelques notions de sécurité et qu'ils imaginent un système plus complexe à détourner.

    Une réflexion à reprendre depuis le début, un peu comme ce qu'a fait Kaspersky avec son OS finalement.

    Source

    Comment installer un plugin sur Discourse ?

    3

    J'ai eu besoin d'installer sur le Discourse, le support des balises BBCode que vous connaissez bien si vous pratiquez un peu les forums. Seulement, nativement ce n'est pas supporté.

    Mais Discourse sur son Github, propose tout un tas de plugins qui permettent d'étendre les fonctionnalités de la plateforme et parmi ceux-là, on y trouve le plugin vbulletin-bbcode.

    Je vais donc en profiter pour faire un petit tuto expliquant comme installer un plugin sous Discourse. Vous allez voir c'est très simple.

    Connectez vous à votre serveur et éditez le fichier de config app.yml qui se trouve logiquement dans /var/discourse/containers/

    Recherchez y la section hooks suivante :

    appyml

    Et ajoutez tout simplement l'URL qui pointe vers le dépôt git. Dans le cas de vbulletin-bbcode, il s'agit donc de https://github.com/discourse/vbulletin-bbcode.git .

    - git clone https://github.com/discourse/vbulletin-bbcode.git

    (Pour l'indentation, utilisez des espaces et pas des tabulations car sinon, vous aurez des erreurs.)

    Oui, rien de plus simple. Pas besoin de télécharger d'archive, et de placer du code. Il suffit juste de spécifier un dépôt git dans le fichier de conf.

    Ensuite, sauvegardez le app.yml et reconstruisez l'application avec la commande suivante (placez vous dans /var/discourse) :

    ./launcher rebuild app

    Et voilà !

    discoursebbcode

    Maintenant vous avez un beau support du BBCode (ou d'autre chose) sur Discourse. D'ailleurs, si vous avez besoin d'autres plugins sur tech.korben.info, n'hésitez pas à me le dire.

    Une faille dans Cryptsetup permet d’obtenir un accès root sur certaines machines Linux

    2

    Hector Marco de l'université d'Écosse de l'Ouest et Ismaël Ripoll de l'école polytechnique de Valence en Espagne, ont révélé l'existence d'une faille de sécurité dans Cryptsetup, qui permet de récupérer un shell de secours en root sur certains systèmes.

    Cryptsetup pour ceux qui ne connaitraient pas, est un outil utilisé pour chiffrer des systèmes de fichiers sous Linux, qui implémente le standard LUKS (Linux Unified Key Setup). C'est ce qui est utilisé par exemple, par défaut sous Debian et Ubuntu lorsque vous activez le chiffrement de votre disque dur.

    A priori, la faille se situerait dans un script livré dans le package Debian cryptsetup  <= 2:1.7.2-3. Si vous êtes sous Fedora, vous êtes aussi concerné, car Cryptsetup est utilisé par Dracut, un outil qui permet de générer des systèmes de fichier en RAM (initramfs).

    La faille CVE-2016-4484 est facile à exploiter. Il suffit d'avoir un accès à une console sur la machine, et lorsque le mot de passe LUKS est demandé, il suffit d'appuyer sur la touche "Entrée" un grand nombre de fois jusqu'à ce qu'un shell apparaisse. On ne peut pas faire plus simple. J'avoue je n'ai pas encore testé, mais les chercheurs à l'origine de la découverte disent que ça ne prend pas plus de 70 secondes.

    Voici une démonstration :

    En effet, une fois que le nombre maximum de mots de passe erronés est atteint, la séquence de boot se poursuit normalement et un autre script présent dans Cryptsetup prend le relai et balance un shell BusyBox ou initramfs.

    Le risque d'exploitation est élevé dans les lieux publics où il y a des bornes Linux (Distributeurs de billets, bornes dans les aéroports...etc.) car il suffit de rebooter la machine en douce (et y brancher un clavier) sans parler de certaines instances Linux accessibles en ligne comme celles proposés par le Cloud Ubuntu, qui d'après ces mêmes chercheurs pourraient être exploitées à distance sans aucun accès physique. Vous trouverez plus de détails sur cette faille ici.

    Bref, autant dire que ça ne sent pas très bon. Pour le moment, seul Debian a patché le truc, sans réagir publiquement, et les chercheurs ne sont pas d'accord avec la façon dont ce patch a été implémenté. D'après eux, le problème est plus général que ça, et viendrait du faire que la séquence de boot GNU/Linux est trop permissive avec les erreurs.

    Et si vous ne voulez pas attendre, les chercheurs proposent le patch suivant à appliquer sur le script "scripts/local-top/cryptroot" :

    screen-shot-2016-11-15-at-2-53-40-pm

    Source

    Librevault

    3

    Disponible sous Windows, macOS et Linux, Librevault est une application qui permet de synchroniser vos données entre plusieurs machines, sans avoir à passer par un serveur tiers. Fini donc les Google Drive et autres Dropbox pour synchroniser vos datas. Avec Librevault, vous pouvez reprendre la main là dessus, sans avoir à configurer quoi que ce soit de complexe.

    screenshot-2016-11-16-07-25-08

    L'outil fonctionne sur un principe de P2P, tout comme BTSync ou encore Syncthing, et a la particularité de tout chiffrer AES-256 en respectant le principe de Zero Knowledge et de transmettre les données en utilisant TLS v1.2. Ainsi la synchronisation peut se faire sur un réseau local ou via Internet.

    Librevault est, comme son nom l'indique, sous licence libre et encore en version alpha. J'ai d'ailleurs rencontré quelques crashs sous Mac et Windows.

    Vous pouvez le télécharger ici :

    3 alternatives gratuites

    à Partition Magic

    Si vous avez besoin de partitionner votre disque dur Windows, de fusionner certaines partitions, d'en formater d'autre ou d'en créer de nouvelles, vous pouvez le faire avec fdisk mais le souci avec fdisk, c'est ...

    6 outils pour cloner un disque

    dur sous Windows et Linux

    Cloner c'est facile... Bon, ok, cloner un bébé, c'est déjà plus complexe mais un disque dur, c'est l'enfance de l'art...Alors bien sûr le logiciel le plus connu ...