Journal Tutoriel d'autohébergement

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
33
27
juin
2012

Bonjour,

Étant actuellement en train de mettre en place quelques services sur un dreamplug, j'ai décidé d'écrire tout mon cheminement à titre d'aide-mémoire.

Voici le plan :

1 Installer Debian sur un disque externe
    1.1 Préparer le disque externe
        1.1.1 Formatage
        1.1.2 Installation d'un système Debian bootable
    1.2 Branchements
    1.3 Installation des logiciels de pilotage
    1.4 Préparation de minicom
    1.5 Connexion à la dreamplug
    1.6 Modification du boot
    1.7 Configurations élémentaires du système Debian
        1.7.1 Corrections de bugs
        1.7.2 Configuration essentielles
        1.7.3 Mise à niveau vers squeeze
        1.7.4 Paquets utiles
    1.8 Créer des utilisateurs
2 Configuration du réseau
    2.1 Associer une ip fixe dans un réseau DHCP
    2.2 Rediriger les ports
3 Configuration du pare-feu
    3.1 Activation
    3.2 Petite documentation
4 Serveur web
    4.1 Ouvrir les ports
    4.2 Installation de lighttpd, MySQL et PHP5
        4.2.1 Installation et configuration élémentaire
        4.2.2 Userdir
5 Documents à distance avec git
    5.1 Initialisation côté serveur
    5.2 Initialisation côté client
    5.3 Aide-mémoire git
    5.4 Un dropbox-like avec SparkleShare
        5.4.1 Côté client
        5.4.2 Puis côté serveur
        5.4.3 À nouveau côté client !
6 Écouter sa musique avec mpd
    6.1 Activer le son sur son dreamplug
    6.2 Installer mpd
    6.3 Configurer mpd
        6.3.1 les dossiers fondamentaux sont :
        6.3.2 Droits et utilisateurs :
        6.3.3 Réseau
    6.4 Droits et base de donnée
    6.5 Du mutisme aux grésillements : encore la carte son !
7 Partage de fichiers avec webdav

Je n'ai pas terminé le document : la partie webdav est vide, et il manque encore deux ou trois trucs (gestion des noms de domaine et sécurité notamment).

Vous trouverez le document ici :

http://jeanbaptiste-bourgoin.com/informatique/autohebergement/dreamplug1.html

N'hésitez pas à me faire part de vos remarques !

  • # Sauvegardes ?

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

    Je ne vois rien sur la sauvegarde du contenu de ton disque.

    Le fait que les disques durs ont tendance a mourir étant ce qui m'a progressivement éloigné de l'auto hébérgement. Mon serveur IMAP a flingué mes disques en 2006 (enfin le disque principal est mort un peu progressivement et l'autre est mort parce que le premier a pas été gentil électriquement en agonisant) et j'ai perdu au passage ce que je ne backupais pas sur une autre machine (genre ma centaine de CD rippés, j'ai encore les originaux mais ca m'a pris du temps de les re-ripper).

    • [^] # Re: Sauvegardes ?

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

      Oui, c'est prévu ;)

      Si quelqu'un a de super conseils dans ce domaine, je suis preneur !

      • [^] # Re: Sauvegardes ?

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

        Étant moi-même en auto-hébergement (sur SheevaPlug), je ne manquerai pas de lire ton tutoriel. Merci pour ce partage !

        En ce qui concerne la sauvegarde, j’ai choisi la solution suivante :
        — Toutes les données importantes du serveur sont exportées en NFS (mais un accès sshfs ou Samba convient très bien aussi),
        — Sur mon PC desktop (qui a nettement plus de puissance), quotidiennement, hebdomadairement et mensuellement, “cron” lance un rsync des données à sauvegarder (lues par NFS) vers une partition locale en ZFS puis j’y fais un snapshot nommé « jour_… », « semaine_… » ou « mois_… ».

        C’est simple et efficace (la partition ZFS est paramétrée en mode compressé et dédupliqué). Et super pratique pour par exemple récupérer le profil Firefox que tu viens de flinguer (au fait, mon plug sert aussi de serveur de synchro FF) ou un document que tu as effacé par erreur.

        Ça ne protège pas d’un incendie ou d’un vol : le PC desktop est au même endroit que le serveur… mais ça protège d’une défaillance de disque.

  • # Sécurité !

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

    • En vrac: un iptables-save bien configuré puis fail2ban et portsentry pour les script-kiddies et enfin un knockd pour planquer les services privés (SSH, FTP, etc.)
    • Protéger son serveur web contre les attaques avec un WAF un mod_security et mod_evasive (je ne connais pas lighttpd donc un équivalent)

    D'autre part penser à installer un client ntp dès le début est IMHO une nécessité.

    • [^] # Re: Sécurité !

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

      Merci pour les conseils. Je suis totalement novice en matière d'auto-hébergement, aussi j'ai mis en place la seule chose que je connais (pare-feu) et j'ai fais attention au peu que je sais en matière de droits.

      Je note fail2ban, portsentry etc.

      J'ai personnellement installé un client ntp mais je n'en parle effectivement pas dans ce document. Je vais ajouter ça, merci !

    • [^] # Re: Sécurité !

      Posté par  . Évalué à 10.

      • En vrac: un iptables-save bien configuré puis fail2ban et portsentry pour les script-kiddies et enfin un knockd pour planquer les services privés (SSH, FTP, etc.)

      Je ne vois pas le problème du scan de port. Okay, on sait que tel service tourne, très bien. Après il faut que ce service soit mal installé/configurer pour pouvoir exploiter une faille. Donc personnellement, je n'installe ni psad ni portsentry.

      Ensuite, j'avait l'habitude d'installer fail2ban, mais je me suis rendu compte que c'était assez cracra (rajouter des règles iptables pour chaque ip bof, bof), et surtout il y a d'autres moyens plus propre pour éviter le brute force que fail2ban.

      • Le premier, c'est qu'on ma expliqué qu'il y avait déjà un méchanisme semblable intégré à SSH (man sshd_config, et regardez du coté LoginGraceTime, MaxAuthTries), je ne l'ai jamais utilisé.
      • L'autre solution que j'utilise, c'est ne n'autoriser que les connections avec les clefs ssh.

      Sinon, on peut utiliser rien de tout ça, et un mot de passe complexe associé à la désactivation du compte root, et normalement il n'y a aucun souci. Si on regarde ce que font les kiddies-scripts qui bruteforce ssh, ils essaient de ce logger en tant que service ou root, alors t'as aucun souci à te faire pour ton compte raoul.

      Knowing the syntax of Java does not make someone a software engineer.

      • [^] # Re: Sécurité !

        Posté par  . Évalué à 3. Dernière modification le 27 juin 2012 à 19:09.

        ils essaient de ce logger en tant que service ou root, alors t'as aucun souci à te faire pour ton compte raoul.

        Pourtant mon honeypot me montre que il y a plein de bots qui essayent un mot de passe "john" à la fois sur "root" et sur un utilisateur "john". Donc prend quand même un mot de passe fort pour ton utilisateur.

      • [^] # Re: Sécurité !

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

        Je ne vois pas le problème du scan de port.

        Chacun est libre de faire ce qu'il veut en matière de sécurité personnelle. Moi j'ai le petit dernier de chez Beretta. Notes bien qu'il faut en avoir l'usage, sans ça au prix actuel tu l'amortis pas…

        alors t'as aucun souci à te faire pour ton compte raoul.

        Ahaha tu m'étonnes !

      • [^] # Re: Sécurité !

        Posté par  . Évalué à 2.

        ils essaient de ce logger en tant que service ou root, alors t'as aucun souci à te faire pour ton compte raoul.

        Un peu plus que "service" ou "root", en fait :

        grep invalid /var/log/auth.log | awk '{print $11}' | sort | uniq | wc -l
107

        "raoul" n'est pas dans la liste, mais d'autres prénoms courants y sont.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Sécurité !

          Posté par  . Évalué à 3.

          Un peu plus que "service" ou "root", en fait :

          grep invalid /var/log/auth.log | awk '{print $11}' | sort | uniq | wc -l
107

          "raoul" n'est pas dans la liste, mais d'autres prénoms courants y sont.

          Quand je dis service, je veux dire les utilisateurs « mysql », « postgres », « www-data », … Donc ça en fait beaucoup.

          Knowing the syntax of Java does not make someone a software engineer.

      • [^] # Re: Sécurité !

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

        Je ne vois pas le problème du scan de port. Okay, on sait que tel service tourne, très bien. Après il faut que ce service soit mal installé/configurer pour pouvoir exploiter une faille. Donc personnellement, je n'installe ni psad ni portsentry.

        +1 Je ne comprends pas non plus quel est le danger d'un scan de port. Connaitre les services disponibles est toujours possible par tâtonnement de toute façon.

        Ensuite, j'avais l'habitude d'installer fail2ban, mais je me suis rendu compte que c'était assez cracra

        +1 également. sshd_config contient tout ce qu'il faut pour avoir un ssh impénétrable. fail2ban donne une fausse impression de sécurité. Mais il n’empêchera personne de se loguer sur un compte test/test admin/admin s'il existe. Au niveau sécurité il avant tout est essentiel de gérer ses utilisateurs et leurs droits. Sur une machine d'hébergement perso, tu devrais avoir typiquement une règle générique interdisant tout par défaut :

        PubkeyAuthentication no
        RSAAuthentication no
        PasswordAuthentication no
        PermitRootLogin no
        …

        Puis des règles explicites par utilisateurs / hotes / Groupes / whatelse

        Match User plop
        PubkeyAuthentication yes
        …
        Match Host 192.168.0.0/24
        PermitRootLogin yes
        PasswordAuthentication yes

        Pour ceux que les script kiddies énervent il suffit de changer de port et de jouer avec paramètres cités plus haut.

        • [^] # Re: Sécurité !

          Posté par  . Évalué à 3. Dernière modification le 28 juin 2012 à 15:01.

          Je ne comprends pas non plus quel est le danger d'un scan de port

          Moi je vois bien : se faire plonker par Octave chez Ovh /o\

  • # Tutoriel ?

    Posté par  . Évalué à 3.

    Je connaissais pas c'est petite bébête (le dreamplug), et je commence à lire un tutoriel qui m'agresse à coup de FAT16, sans explication !

    Bref, dans un tutoriel, j'aime bien qu'on m'explique ce que je fait et surtout pourquoi je le fait. Je suppose que c'est une astuce lié au matériel et que les personnes qui sont familières avec cette astuce n'ont peut-être déjà plus besoin de ce tutoriel.

    Voilà, c'était juste une critique sur la forme, sinon merci pour le partage

    • [^] # Re: Tutoriel ?

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

      La partition FAT16 permet de booter sur le disque usb depuis une image linux. Les raisons techniques précises, je ne les connais pas. Il me semble que le "uboot" de dreamplug permet de booter sur une partition ext2 également.

      Je connais très peu la machine encore, je viens de la recevoir. Je n'avais jamais touché à un JTAG auparavant. Ce document est plus un "carnet de route" qu'un tuto en provenance d'une personne qui connaîtrait suffisamment bien le sujet pour tout expliquer avec clarté et profondeur de vue ;)

      En tout cas, merci pour le retour, le document est encore trop elliptique. Il faudra un travail de nettoyage et de clarification.

  • # Autres services

    Posté par  . Évalué à 1.

    Ne penses-tu pas à installer un service de mail ? Il me semble que ceci serait intéressant.

    Après je pense qu'il doit y avoir quelques autres services utiles, mais je ne les ai pas en tête.
    Alors si vous avez des idées… je suis aussi preneur.

    • [^] # Re: Autres services

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

      C'est prévu, mais pas pour tout de suite. Ce "carnet de bord" évolue à mesure que je travaille sur ce serveur, et comme je suis débutant il me faut me documenter avant ;)

  • # Duo

    Posté par  . Évalué à 4.

    Tu es un mixe de Tanguy Ortolo et de ploum ?

  • # À diffuser !

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

    Le monde de l'autohébergement étant un petit monde, ta documentation pourra intéresser du monde sur le wiki correspondant.

    C'est en tout cas une très bonne idée de noter tout ça… Quand on ne passe toute la journée à administrer des machines, ça permet d'éviter de se demander comment regénérer les certificats expirés. (Dont tu ne parles pas d'ailleurs…)

    Après l'auto hébergement, c'est aussi avoir un serveur chez soi : samba, cache dns, privoxy, et j'en oublie…!

    • [^] # Re: À diffuser !

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

      Poste le aussi sur le wiki de linuxfr !

      Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

    • [^] # Re: À diffuser !

      Posté par  . Évalué à 3.

      ta documentation pourra intéresser du monde sur le wiki correspondant.

      À ce propos, ça serait bien que notre Ortolo national n’utilise pas ortolo.eu dans le CN du certificat SSL de {,wiki.}auto-hébergement.fr

    • [^] # Re: À diffuser !

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

      Oui, j'y ai pensé, mais je préfère que le document soit un peu plus fignolé avant de le proposer.

  • # minicom ....

    Posté par  . Évalué à 2.

    Salut,
    plutôt que minicom, essaye 'screen', avec une commande comme celle-ci:

    screen /dev/ttyUSB0 115200

    (le 115200 étant le débit de la ligne série)

    Tu n'en parles pas dans ta doc, mais l'image pour le DP est fournie avec un script tout "moisi" : /root/init_setup.sh
    Je l'ai personnellement remplacé par un script plus "propre" (je peux te l'envoyer, au besoin).

    Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.

  • # Remerciement et signalement d'un petit bug

    Posté par  . Évalué à 1.

    Jean-Baptiste

    Merci pour ce mémo très instructif.

    Au cours de la lecture de ton document avec firefox 9.0.1, les liens "Top", "Previous" et "Next" fonctionnent correctement. Par contre, le bouton "reculer d'une page" de ce navigateur ne fonctionne pas comme prévu à partir d'une sous page : le navigateur n'affiche pas la page précédente mais la page consultée avant l'index !

    Par exemple, si je consulte les pages :
    http://jeanbaptiste-bourgoin.com/index.html
    http://jeanbaptiste-bourgoin.com/informatique/autohebergement/dreamplug1.html
    http://jeanbaptiste-bourgoin.com/informatique/autohebergement/dreamplug1.html#sec-1-1

    puis si je clique sur le bouton "reculer d'une page", firefox affiche la page http://jeanbaptiste-bourgoin.com/index.html et non la table des matières.

    Cordialement

    Slack

  • # Pourquoi Debian

    Posté par  . Évalué à 1.

    Dès la première ligne, une question m'assaille : pourquoi Debian ? Y'a pas plus adapté ? Genre un truc plus à jour et plus orienté embarqué ?

    • [^] # Re: Pourquoi Debian

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

      C'est assez simple : c'est ce que je connais le mieux.

      Je suis un "newbie" en matière d'auto-hébergement et d'embarqué, alors j'avoue que je me suis contenté de ce que je "maîtrise" en matière d'OS ;)

      Et puis, ça fonctionne très bien alors…

      • [^] # Re: Pourquoi Debian

        Posté par  . Évalué à 3.

        C'est assez simple : c'est ce que je connais le mieux.

        C'est une raison largement suffisante, à mon avis.

        Je pense que Debian est un très bon choix (c'est mon choix de prédilection également).

        Si jamais tu devais avoir des contraintes de ressources (RAM, CPU, disque, etc.), jette un coup d’œil du côté de Slitaz.

        Le FN est un parti d'extrême droite

    • [^] # Re: Pourquoi Debian

      Posté par  . Évalué à 3.

      Dès la première ligne, une question m'assaille : pourquoi Debian ?

      Parce qu'elle se veut un OS universel et qu'elle y arrive plutôt bien, je trouve.

      Genre un truc plus à jour

      Debian testing est presque aussi fiable qu'une stable et aussi à jour qu'une Ubuntu.

      et plus orienté embarqué ?

      Comme pas mal d'autres distributions, Debian est parfaitement modulaire et peut être adaptée sur de nombreux matériels.

      En tout cas, elle tourne sur mes tablettes N810 et Archos.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Pourquoi Debian

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

      Plus à jour pour quoi faire ? Surtout côté serveur… Les mises à jour de sécurité sont là, pour le reste…

  • # Sécurité et pdf

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

    Bonjour,

    Je viens d'apport quelques corrections mineures, un début de chapitre sur la sécurité (quelques points sur ssh pour le moment) et un lien vers une version pdf très "sommaire".

    • [^] # Re: Sécurité et pdf

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

      Salut,

      Contrairement à ce que tu penses ton SSH n'est pas totalement sécurisé. Changer le port par défaut ne sert à rien d'autre qu'à réduire le bruit dans les logs (un scan révélera immédiatement le port de ton SSH). Par contre avoir un second SSHD (voire plus) sur un autre port peut être parfois très très utile…

      Si tu ne veux pas le planquer derrière un knockd (ce qui permet d'ouvrir et fermer le port de façon dynamique depuis n'importe quelle IP à l'aide d'une séquence secrète), désactives les mots de passe pour n'autoriser que les connections par clé (ECDSA de préférence mais plusieurs c'est mieux). As-tu vraiment envie de taper ton mot de passe en environnement hostile (ie. sur un Windows avec un Keylogger par ex, ou un réseau inconnu) ?

      D'autre part les option LoginGraceTime et MaxAuthTries ne sont pas des parades car l'attaquant voit juste sa session se fermer et n'a plus qu'à en ouvrir une autre, ce que les robots (99% des tentatives à la louche) font automatiquement.

      Enfin pour ternir encore un peu le tableau, il existe (existait?) des botnet (cf. "hail mary cloud") qui tentent des attaques distribuées par dictionnaire et brutforce. Dès qu'une IP/machine se fait jeter elle passe la main à une autre qui reprend l'attaque là où l'autre l'avait arrêté. Bref un mot de passe peut tenir un certain temps en fonction de sa complexité mais finira par être découvert tôt ou tard.

      Bon, toutes ces mesures peuvent paraître peut-être un peu disproportionnées pour de l'auto-hébergement mais les connaître est parfois utile…

      • [^] # Re:Sécuritéet pdf

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

        connections par clé (ECDSA de préférence mais plusieurs c'est mieux). As-tu vraiment envie de taper ton mot de passe en environnement hostile (ie. sur un Windows avec un Keylogger par ex, ou un réseau inconnu) ?

        De ce point de vue (machine corrompue) que change une clé ?

        • [^] # Re:Sécuritéet pdf

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

          Il faut pour se connecter avoir la clé ET la phrase de passe associée. Si tu gardes tes clés dans un trousseau sécurisé tu as moins de chances de te la faire piquer. En plus dans le fichier authorized_keys du serveur tu peux mettre plein d'options spécifiques à une clé pour en limiter l'usage. Donc avoir une clé pour les connections nomades est IMHO une bonne pratique.

          • [^] # Re:Sécuritéetpdf

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

            J'utilise les clés, pour pas me faire chier et pour limiter le bruteforce.
            Mais d'un point de vue securité quand tu es sur une machine corrompue, c'est pas plus compliqué de faire une capture du mot de passe ssh que de faire une copie de la clée et une capture du mot de passe de la clé non ?

            • [^] # Re:Sécuritéetpdf

              Posté par  (site web personnel) . Évalué à 2. Dernière modification le 28 juin 2012 à 12:55.

              Oui, peux-être as-tu raison, mais tu peux protéger tes clés de multiples façons non ? Sinon il y a les certificats mais je n'ai pas encore testé.
              Ce dont je n'ai pas encore parlé et que j'utilise en plus des clés en environnement hostile c'est OPIE. De toutes façons je n'ouvre le port que le temps nécessaire.
              Mais pour celui qui ne veut pas de knockd, OPIE (alias OTP One Time Password) c'est indispensable.

      • [^] # Re: Sécurité et pdf

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

        Merci pour les infos  !

        Que valent des mots de passe évalués 256 bit par Keepass ?

        • [^] # Re: Sécurité et pdf

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

          Désolé je ne connais absolument pas.

          • [^] # Re: Sécurité et pdf

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

            Je génère mes mots de passe avec KeepassX. On peut renseigner des options type "chiffre", "longueur", "caractères spéciaux" etc. À partir de là KeepassX fait une estimation de la solidité du mot de passe. En fait, je voulais juste savoir ce que cette estimation valait ;)

      • [^] # Re: Sécurité et pdf

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

        J'oubliais : j'ai désactivé l'accès ssh en root bien sûr.

        Il va falloir que je me penche sur cette histoire de sshd sur plusieurs ports. Mais je ne comprends pas bien quel est l'intérêt ?

        • [^] # Re: Sécurité et pdf

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

          J'oubliais : j'ai désactivé l'accès ssh en root bien sûr.

          C'est une bonne chose.

          Mais je ne comprends pas bien quel est l'intérêt ?

          Il y en a plein. Chaque instance de sshd a son port d'écoute ET sa propre config. Par ex tu peux faire tes tests avec un port != 22 et une fois que tout fonctionne tu remplace le fichier sshd_config par celui de test. Ensuite quand tu feras du forwarding/vpn tu verras que c'est très pratique.

      • [^] # Re: Sécurité et pdf

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

        Changer le port par défaut ne sert à rien d'autre qu'à réduire le bruit dans les logs (un scan révélera immédiatement le port de ton SSH)

        Tu ne ressent pas une certaine contradiction dans ton propos. Changer le port par défaut bloque les attaques sans intelligences qui sont les plus nombreuses. Tu ne peux pas juste balayer ça en disant "ne sert à rien". Met deux machines en ligne avec un compte test / test et un shell à la con; une sur le port 22, une sur un autre port et observe laquelle est pétée le plus vite.

        Bref un mot de passe peut tenir un certain temps en fonction de sa complexité mais finira par être découvert tôt ou tard.

        Tard est largement suffisant. La complexité d'un mot de passe dépend avant tout de sa présence dans un dictionnaire. Craquer un mot de passe aléatoire par tentative de connexion ssh est trop couteux. Je ne l'ai vu que pour des mots de passes à la con. Ou dans des cas bien particulier (utilisateur ayant le même mot de passe partout, ou presque le même avec des variantes). C'est possible mais je n'y crois pas. L'essentiel en sécurité est quand même de toujours gagner du temps. C'est pour ça que tu met une porte blindé. Pas parce qu'elle est inviolable mais parce qu'elle est trop longue à ouvrir.

        Par contre on est bien d'accord que l'authentification par clé est à privilégier.

        L'essentiel des risques viennent du vol de mot de passes (keylogueurs sous Windows,transmission par mail …), d'erreurs (on a oublié un compte de test par exemple ou de changer un mot de passe par défaut) ou d'escalade (on passe d'un shell php en nobody à un bash en user, à root grace à sudo ou à suid et de root à noyau par modprobe …)

        C'est pourquoi je pense que la base est l'administration des comptes utilisateurs : gestion fine des droits pour chaque service, un utilisateur different par service, l'habitude de tout interdire par défaut, le renouvellement régulier des mots de passes, l'imposition de mots de passes aléatoires, le bannissement des utilisateurs virtuels à la con qui ont tous la même uid, pas de chown/chmod intempestif, pas de sudoers écrit a la louche, pas de chmod +s inconsidéré, pas de /etc/shells contenant tout et n'importe quoi … C'est ça avant tout qui déterminera l'impact d'une attaque et c'est valable pour ssh comme pour le reste.

        Quand cela est acquis tu peux commencer à parler de failtoban, de knockd … etc … mais ces outils ne sont rien si tu ne gères pas tes comptes. Si tu ne gères pas tes comptes, tu te fera péter tôt ou tard, failtoban ou pas.

        Mes deux cents
        Joris

      • [^] # Re: Sécurité et pdf

        Posté par  . Évalué à 1.

        Est-il possible de faire une authentification sécurisée qui demande à la fois le mot de passe et la possession d'un objet personnel, comme un téléphone portable ou une adresse mail, pour se logguer ? En environnement potentiellement hostile, il faudrait entrer le mot de passe, un code serait renvoyé sur le téléphone/une adresse mail, et ce code devrait être renvoyé à SSH pour finir l'authentification.

        A domicile une clé conviendra bien sûr, et permettra de ne pas perdre sa machine si on perd son téléphone/sa boite mail.

  • # Puissance du bazar

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

    Je me pose de plus en plus la question d'acheter un bidule de ce genre.

    Pour héberger un rsslounge, un smtp+imap+webmail, Piwigo pour héberger les photos, et deux trois pages/applis diverses (wiki perso par exemple).

    Je suis attentif à la consommation annuelle et à l'encombrement, donc une dreamplug ou assimilée m'arrangerait bien. Mais est-ce pertinent en terme de performances vu ce que je veux y mettre? Vu que je compte migrer le mail de ma conjointe dessus, ça serait bien que ça rame pas, sinon son retour chez gmail sera rapide.

    Prochainement, je vous proposerai peut-être un commentaire constructif.

  • # Quelques remarques

    Posté par  . Évalué à 2.

    Hello,

    Sympa de partager ton expérience.

    Je vois que tu mentionnes git dans tes installs. Pourquoi ne pas mettre ton tuto sur gitorious ? Au moins on verra les évolutions (c'est plus simple que de repasser ici expliquer ce qui a changé et laisser le lecteur trouver le passage).

    Toujours sur git, je te conseilles vivement d'installer etckeeper, histoire de versionner ton /etc. C'est très pratique pour faire un rollback rapide ou bien suivre l'évolution des configs.

    D'autre part, puisque tu souhaites installer une Debian, pourquoi tu n'utilises pas directement deboostrap pour installer une Wheezy ? Je ne connais pas très bien le contexte, peut être que ce n'est pas justifié dans ce cas, mais, du peu que je vois, ça me semble être préférable.

    Dans la liste des paquets essentiels, je te conseille aussi de rajouter molly-guard (pour éviter de rebooter des serveurs par erreur) et debian-goodies (notamment pour checkrestart qui permet d'éviter les trous de sécurité en redémarrant ce qui doit l'être).

    Et pour finir, tu parles d'apache et lighttpd. Pourquoi pas nginx ? Il est plus léger qu'apache et bien plus répandu que lighttpd (il est même devant iis).

    Sinon, quelques correction orthographiques toutes dans le même paragraphe :
    * il vous sera demander
    * faite bien attention
    * et de chiffres.A

    Le FN est un parti d'extrême droite

  • # Attention aux proxies

    Posté par  . Évalué à 1.

    Ça me fait un peu marrer toutes ces discussions sur l'utilité de mettre son accès ssh partout, de faire des manipulations de malade pour éviter les méchants.

    Attention, je sais que c'est utile. Mais voilà, un jour, tu seras derrière un proxy qui n'autorisera que les ports 80 et 443. Et toi, tu auras besoin de te connecter chez toi.

    Je te conseille shellinabox, qui est un shell dans un page web. Il suffit de le mettre en HTTPS, via une adresse obscure (genre /monaccèssecret). Et ça dépanne, tu peux pas imaginer :)

    Ensuite, j'utilise sslh, mais ça, c'est optionnel. Ça permet d'avoir du SSH et du HTTPS sur le port 443. Mais ça n'empêche pas un proxy bien fait de le bloquer.

    C'est tiré de mon expérience personnelle ;)

Suivre le flux des commentaires

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