aurel a écrit 1319 commentaires

Il y a comme une histoire de curseur à mettre, dans cette histoire.

Si c'est hacker qui t’intéresse, quitte à devoir y passer un peu de temps (surtout au début, après ça roule), mieux vaut se retrousser les manches.

Si c'est la protection de la vie privée, il est tout à fait possible de rester chez un fournisseur type Gmail ou Yahoo, en chiffrant systématiquement avec GPG. Au passage, tes correspondants et toi y perdrons la recherche, mais tu gagneras un temps fou à te reposer sur leur infrastructure.

Cependant, il me semble difficile de faire l'impasse sur GPG, même en s'occupant de l'hébergement des mails, pour au moins 2 raisons:

1/ les mails sont stockés en clair sur ton serveur et en cas de compromission de ce dernier, tout est donc rendu public,

2/ et surtout: tous tes correspondants ne sont sans doute pas hébergés sur ton serveur, et tu as donc, de fait, des dépendances avec d'autres prestataires que tu ne contrôle pas (Gmail, Yahoo, etc.) et qui scannent tes mails lorsqu'ils les reçoivent.

Dernier point: ce choix que tu peux faire de préserver le peu qu'il reste de vie privée, ou d'héberger tes mails, a un impact sur tes correspondants qui vont soit devoir se mettre à GPG (dur de convaincre…), soit utiliser une adresse email crée sur ton serveur, soit les deux. De ma propre expérience, ce n'est pas gagné, mais ça marchouille :)

A.

Ben alors ? Personne n'est intéressé ? Surprenant !

Pour ma part, je comprends ta démarche, et poster ici a le mérite de m'avoir faire creuser un peu. N'ayant pas de chromebook sous la main, je serais bien en peine de faire un retour d'expérience. Toi, par contre, si tu te diriges vers cette option là, n'hésite pas à nous faire part de ton feedback :)

Aurel.

En non-libre, mais drôlement efficace, tu as bittorrent-sync. Il ne fait que le partage de fichier, ce n'est donc pas un remplaçant de Owncloud.

Pour ma part, j'utilise le partage de fichier/agenda/contact proposé par Owncloud depuis un petit moment, et je trouve que la fiabilité de la chose s'est progressivement améliorée. Il faut dire qu'elle partait de loin, et même aujourd'hui je ne lui confierais pas des missions critiques. Je suis tout tremblant à chaque mise à jour :D

Au pire, ça doit pouvoir se gérer avec pavucontrol…

-> []

Adobe Brackets, qui a récemment fait parler de lui ici ?

Tout est dans le titre :)

Compter 30 euros pour les premiers prix, bien moins cher que le matériel nécessaire pour faire tourner pfsense.

… quel hébergeur choisir ?

Visiblement c'est le paragraphe 7.4 du contrat des VPS qui interdit les intrusions et tentatives d'intrusions, qui sont de toute façon illégale, et ce à travers leurs technique… qui sont aussi celles utilisées pour faire des audits même si ces derniers sont légaux. La barbe.

Merci pour le témoignage, même si savoir que je ne suis pas le seul à être enquiquiné ne me console pas vraiment. Chez qui est-ce que vous avez déménagé, si ce n'est pas indiscret?

Ils savent sans doute qu'une telle alliance serait vouée à l'échec car elle ne serait pas en mesure de prendre l'ascendant sur MultideskOS.

Sinon, moi j'utilise vim (on est samedi).

Merci à tous les deux.

Je n'observe aucune différence que KeepAlive soit sur Off ou sur On: dans les 2 cas, le site est rapide lorsque KeepAliveTimeout est à 0, et lent lorsqu'il est à 5.

Drôlement bizarre :S

Je viens de trouver l'origine du problème: apache2 avait un KeepAliveTimeout de 5s. En le passant à 0s, ça fonce.

KeepAliveTimeout: Number of seconds to wait for the next request from the same client on the same connection.

Puisque toutes les requêtes proviennent du reverse proxy, il vaut mieux ne pas attendre du tout entre deux. Un vrai coup de bol d'être tombé sur cette solution.

Merci pour ton aide en tout cas, même si au final c'était tout autre chose !

Aurel.

Merci beaucoup pour tes suggestions.
- Tout semble bon côté DNS
- Le chiffrement est optionnel (uniquement jusqu'au reverse proxy) et la lenteur est observée avec et sans lui
- les VZ sont bien plus puissante que ce qui est nécessaire. iotop et top sur l’hôte physique me donne l'impression que ce dernier se repose tranquillement.

apt-get install pwgen
pwgen --secure -y 50

Encore moins classe qu'apg :D

Trois bémols:
- laspass n'est pas libre, quid de la confiance ?
- sauf erreur, lastpass propose une interface web, ce qui implique qu'ils peuvent déchiffrer les mots de passe qu'ils conservent avec le mot de passe lastpass de l'utilisateur
- il y a eu des rumeurs (confirmées?) indiquant que lastpass a déjà été compromis par le passé

Autant préférer une solution basée sur un keepassx par exemple, qui est multiplateforme. Il suffit de stocker le fichier contenant les mots de passes sur un système de fichier accessible depuis n'importe où et idéalement depuis un endroit qui ne dépend pas d'un tiers (genre autohébergé). Couplé à un Firefox Sync auto-hébergé:
- tes navigateurs se rappellent pour toi de tous les mots de passe
- si tu n'es pas sur ton navigateur habituel, tu peux accéder à ton fichier keepassx via ton smartphone, ou en ligne de commande par SSH, par exemple

Après, c'est moins intégré que à ton surf que lastpass (autocomplétion des formulaires, toussa) mais au quotidien c'est sans doute + sûr et vraiment pas contraignant.

Hello!

Un petit bricolage: un cronjob qui lance un script qui vérifie si ton fixe est accessible, et qui le cas échéant lance un rsync.

Un peu moins bricolage: un des nombreux Dropbox-like. Bittorrent Sync est efficace en plus d'être léger et rapide, mais il n'est pas opensource. Sinon, des choses comme DVCS-Autosync (pas testé, mais le principe est séduisant).

Mes 2c…

Sauf erreur, la sécurité d'un 128 bits symétrique, c'est peu ou prou celle d'un 2048 en asymétrique :)

Héhé, MacOS est vulnérable aussi :-D

Pour faire simple:
- sauf erreur de ma part, Proxmox ne gère pas le RAID soft
- c'est possible de "convertir" une Debian en Proxmox (cf. ici)

=> pourquoi ne pas installer une Debian toute bête, sur 2 disques coupés chacuns en 2 partitions:
- /dev/sda1+/dev/sdb1 en RAID1 visibles comme /dev/md0 pour le système
- /dev/sda2+/dev/sdb2 en RAID1 visibles comme /dev/md1 pour tes containers

Doubles cerises sur le gâteau:
- si tu aimes le mille feuille (et ça à l'air d'être le cas): tu rajoutes un LVM pour chacun de tes 2 RAIDs1, histoire de pouvoir faire des snapshots lors des mises à jour, pour pouvoir tout restaurer facilement en cas de problème.
- si tu aimes beaucoup le mille feuille, tu rajoute entre le RAID et le LVM un chiffrement par LUKS par exemple, histoire qu'une méchant cambrioleur ne puisse pas accéder à tes données, si d'aventure il repart avec la machine sous le bras :-)

De cette façon, tant d'OS que les containers résisteraient au crash d'un disque, aussi bien qu'à une mise à jour hasardeuse, tout en restant à l’abri en cas de vol :-)

Pour ma part en tout cas, c'est ce que je ferais… et d'ailleurs ça tourne comme ça chez moi depuis pas mal de temps, sans aucun problème :-)

Aurel.

Bonne nouvelle: je commence à comprendre ce que tu veux dire, même si aucune explication évidente ne me vient à l'esprit, sinon que ça "juste marche" dans tous les test que j'ai pu faire hors d'OpenVZ: entre machines physiques ou machines virtuelles dans VirtualBox, avec des Ubuntu Server 12.04.2 LTS :)

Mon noyau est le 2.6.32-20-pve de proxmox. J'utilise SSH de la même façon que ce qui est décrit ici: https://help.ubuntu.com/community/SSH_VPN, sauf que je ne veux pas relier 2 réseaux, mais simplement accéder à une autre interface réseau (Y.Y.Y.Y) de la machine B depuis la machine A.

PS: Si ça peut faire avancer le schmilblick, je précise que les adresses X.X.X.X et Z.Z.Z.Z sont routables, contrairement à Z.Z.Z.1/2 qui sont privées (10.0.X.X).

Hello!

Merci pour ta réponse: à défaut de résoudre le problème, ca fait travailler les méninges :-)

tu à Y.Y.Y.Y qui ouvre une session SSH vers X.X.X.X. Ensuite tu fait des bidouilles sur X.X.X.X, puis ensuite, tu rajoute, comme ça, salement, sur X.X.X.X une route vers Y.Y.Y.Y qui passe pas là ou ça passait d'habitude.
Sauf que pour router ton traffic SSH, le noyau va utiliser ta table de routage. Si quand le démon SSH veut aller renvoyer du TCP à Y.Y.Y.Y, il passe par ton tunnel, c'est mort. Je ne comprend pas comment ça à pu marcher tel quel. T'est sûr qu'il n'y avais pas du NAT entre les deux la première fois ?

Pour simplifier le tout, c'est depuis une 3ème machine que je me connecte sur X.X.X.X et Y.Y.Y.Y pour faire tous mes bricolages :-)

Lorsque Y.Y.Y.Y se connecte par SSH sur X.X.X.X, c'est juste pour créer les 2 interfaces tun1. À ce moment là, je peux pinger MachineA/Z.Z.Z.1 depuis MachineB/Z.Z.Z.2 (et vice-versa).

Si MachineA n'est pas un container OpenVZ, il me suffit de lui ajouter la nouvelle route vers Y.Y.Y.Y en passant par Z.Z.Z.2, et d'avoir l'IP forwarding d'activé sur MachineB pour pouvoir pinger Y.Y.Y.Y depuis MachineA. Je ne vois pas bien où est-ce que j'aurais besoin du NAT dans cette histoire, puisque ca marche très bien sans? À moins que je rate quelque chose?

Si MachineA est un container OpenVZ, l'ajout de la route n'a pas les même conséquence, et rend impossible les pings:
* de Z.Z.Z.2 depuis MachineA/Z.Z.Z.1 (et vice-versa), alors que ca me semble totalement indépendant de la route que j'ajoute
* de Y.Y.Y.Y depuis MachineA/Z.Z.Z.1

C'est quand même bizarre non ? Ou bien ?

Aurel.

PS: merci je note pour ip addr et ip route :-)

Malheureusement, je n'ai pas la main sur le firewall, mais merci quand même :-)

Pour chiffrer: d'encfs à ecryptfs à truecrypt à dm-crypt à…

Pour accéder au filesystem chiffré: sshfs ou n'importe quoi d'autre, y compris des alternatives discutables (dropbox, etc.).

mes 2c….

… j'aurais plutôt pensé à une démarche par voyages-sncf

-> []

En fait, non, je re-rentre: bon courage !

Heu… ce ne serait pas plutôt aux juges de prouver que tu es coupable, plutôt qu'à toi de prouver que tu es innocent? Ou bien?