Forum Linux.debian/ubuntu Boot pxe chiffré

Posté par  . Licence CC By‑SA.
Étiquettes :
1
8
jan.
2018

Bonjour,
Je cherche à faire démarrer Debian sur des pc sans disque dur via le réseau mais sur un réseau hostile.

Pour la phase du chargement du Kernel j'ai déjà trouvé.
Je charge depuis le dhcp ipxe qui est signé et chiffré et les clés se trouvent dans l'uefi et ensuite par https je récupère le kernel.

Mais pour le rootfs je bloque.
J'ai pensé à glusterfs, mais j'ai pas trouvé de solution simple pour l'intégrer dans l'initramfs.
J'ai pensé à nfs avec du ipsec mais la aussi je vois pas trop comment faire.
J'ai pensé à du nbd avec lucks mais si le root n'est pas le device nbd alors l'initramfs ne le connecte pas.

La protection que j'aimerai apporte est d'éviter l'aspiration du rootfs par une attaque de l'home du milieu.

Si vous avez des pistes ou des débuts de réflexion je suis preneur.
Merci de m'avoir lu :)

Tharyrok

  • # des pistes

    Posté par  . Évalué à 3.

    J'ai pensé à nfs avec du ipsec mais la aussi je vois pas trop comment faire.

    monter l'ipsec dans l'initramfs,
    puis seulement quand l'ipsec est monté, activer le NFS
    puis changer de "rootfs" via le pivotroot pour basculer de celui de l'initramfs vers celui du NFS

    c'est un peu ce qui se fait quand tu demarres avec une partition root chiffrée,
    tu montes le noyau et l'initramfs, puis tu dechiffres la partition, tu la montes, et tu bascule root dessus

    • [^] # Re: des pistes

      Posté par  . Évalué à 1.

      Tu as une doc ou une méthode pour monter l'ipsec dans initramfs ?

      Je m'étais orienté vers openvpn et je ne sais pas entre ipsec ou openvpn ce que je vais choisir.

  • # je comprend pas le pb du rootfs

    Posté par  (site web personnel) . Évalué à 1.

    ou plutôt pourquoi utiliser un rootfs remote?

    il y a longtemps que je n ais pas monter un truc du genre, mais quand je l avais fait j avais construit un squashfs qui comprenait le rootfs que je voulais, et je l updatais au besoin.

    ensuite avec le montage qui va bien pour pouvoir faire des updates ou install de packages supplémentaire (un peu).

    ensuite si ta contrainte est d avoir un système qui reste up tres longtemps ce n est pas une bonne solution, mais si ces pour être en ligne plusieurs heures ou qq jours alors c est ok, et peut etre de penser a un processus d update du squashfs touts les jours pour intégrer les updatdes.

    si tu veux tester la procédure, en ipxe c est assez facile, j ai retrouver ca dans mes archives :)

    tu dois positioner les bonnes variables pour pxebbot et pxeboot-ip qui sont la ou se trouve lee kernel, l initrd et le squashfs (en hhtps pour toi)

    set boot-kernel ${pxeboot}/kernels/vmlinuz.debian.live
set boot-initrd ${pxeboot}/kernels/initrd.img.debian.live
set imgargs fetch=${pxeboot-ip}/kernels/debian.live.squashfs boot=live textonly toram live-getty live-netdev=eth0
goto boot_linux

    et le menu boot_linux est 

    :boot_linux
imgfree
kernel ${boot-kernel} ${imgargs}
initrd ${boot-initrd}
boot

    adapte à tes besoins. si tu as des questions n hesite pas à demander.

    sinon tu peux aussi monter le nfs en nfsv4 avec kerberos avec le paramètres sec=krb5p.

    montrer une infra kerberos peut être délicat si tu n est pas confirmé, car cela utilise beaucoup de notions et de setup, mais ca en vaut la peine.

    car si tu kerberise tes machines, tu pourra même mettre une infra de SSO avec un effort tres minime car mettre le kerberos correspond a 90% de cet effort.

    /Bon courage

    • [^] # Re: je comprend pas le pb du rootfs

      Posté par  . Évalué à 1.

      ou plutôt pourquoi utiliser un rootfs remote?

      Raison historique, le souci que j'ai c'est de rendre le système utilisable sur un réseau hostile et ne pas trop changer les habitudes.

      ensuite avec le montage qui va bien pour pouvoir faire des updates ou install de packages supplémentaire (un peu).

      Je ne maitrise pas le cycle de mise à jour, actuellement on publie via ssh sur les serveurs nfs les mise a jours.

      ensuite si ta contrainte est d avoir un système qui reste up tres longtemps ce n est pas une bonne solution, mais si ces pour
      être en ligne plusieurs heures ou qq jours alors c est ok, et peut etre de penser a un processus d update du squashfs touts les jours pour intégrer les updatdes.
      On a des pc montés en nfs avec plusieurs jours (voire semaine) qui sont up, nfs n'est pas le souci.

      sinon tu peux aussi monter le nfs en nfsv4 avec kerberos avec le paramètres sec=krb5p.

      Vraiment overkill pour nous, ensuite l'initramfs de debian ne supporte la v4 de nfs.

      /Bon courage

      Merci beaucoup et pour ce commentaire

      • [^] # Re: je comprend pas le pb du rootfs

        Posté par  (site web personnel) . Évalué à 1.

        mais sid le nfsV4 est ok avec debian, aucun soucis

        le tout est de faire sont environnement de build live debian avec son propre kernel, il faut juste adapter et configure le live comme il faut.

        la publication des mise à jour c est pour les binaires systèmes.? ou des environement tiers.

        car si c est pour des binaires tiers, le nfsv4 avc montage de /opt et le $PATH qui vas bien dsevrait répondre a tes besoins

        disons que je manque un peu de contexte pour vraiment bien répondre à la problématique

        j avais fait qq chose d similaire pour un environnement unsafe (salon commercial), le linux bootait en live avec un kernel custo (bcp de paramètres non standard), et des binaires up2date, ensuite au boot ca téléchargeait un gros kit de notre site (tar.gz) et lançait l install + paramètres et lancement du soft (que des commerciaux sur place donc fallait que ca soit 100% auto). Donc a priori un truc équivalent devrait te convenir, surtout si tu peux te passer du NFS, est ce qu il est reelement nécessaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.