Ou est-ce marqué que c'est une utilisation "amateur" ? La personne s'annonce avec l'identifiant AdminSec et dit elle même "je commence avec les tache planifiée".
Demain j'ouvre un compte "ManuMacron" et je suis le président? ;-)
Et d'ailleurs, il l'écrit et tu le cites: "il commence avec les tâches planifiées".
Il le redit d'ailleurs dans un commentaire un peu plus bas:
Très bien merci à vous, dans mon cours il me disait de passer par cette commande
Et excuse moi, il me parait plus logique d'apprendre d'abord la méthode qui marche partout (aka crontab -e) avant de s'orienter vers les évolutions introduites par Linux et les *bsd, aka /etc/cron.{d,daily,weekly,monthly}
Pour finir sur le sujet cron, AdminSec est étudiant … à mon époque (pas si lointaine), on avait pas l'accès root au serveur utilisé pour les TP … tu fais comment sans crontab -e dans ce contexte, quand tu es un simple user ?
C'est comme les bashismes: perso, je conseillerai à un étudiant d'apprendre à correctement se servir de /bin/sh "de base" avant de s'envoyer sur les bashismes…
Pour continuer sur ton commentaire, dans un monde pro:
Tu versionnes correctement ces fichiers via git ou autre outil.
Tu commentes abondamment les modifications pour que tes co-admins aient l'historique.
Partant de ces deux "bonnes pratiques de base", je ne vois pas ce que ça change d'avoir 1 fichier par "tâche" VS 1 fichier pour toutes les tâches.
En outre, et toujours dans le monde pro:
Tu dois parfois composer avec des Unix proprios exotiques et antédiluviens (mode "on touche pas, ça marche") et:
Tes commandes sont executés dans le working directory de cron ce qui n'est pas l'effet souhaité.
Il faut plutôt utiliser des chemins absolus: plutôt que ./DistUpgrade tu peux plutôt utiliser /home/<ton user>/<le rep de ton choix>/DistUpgrade et ce pour tout tes commandes.
Si tu souhaites ne pas répéter ce chemin (et faire des erreurs au passage), tu peux déclarer une variable, TARGET_DIR=/home/<ton user>/<le rep de ton choix>/DistUpgrade puis ensuite utiliser ${TARGET_DIR}/DistUpgrade.
En effet, c'est du bon vieux Xeon.
Par contre, l'idée est de se baser autant que faire se peut sur du wifi (pas encore tiré le RJ partout …).
Je ne sais pas du tout si le WoL fonctionne sur du wifi …
La solution peut me convenir, même si elle demande quand même un minimum de taf d'intégration …
Je vais quand même voir si il n'y a pas quelque chose de plus "plug-n-play", mais merci pour la piste !
Le problème n'est pas tant d'éteindre le serveur (pour le coup un shutdown ou halt -p fait l'affaire), mais plus de le rallumer.
Une fonctionnalité intéressante des machines rackables ou plus généralement à vocation serveur, est leur capacité à s'allumer après un powercut.
C'est un allumage à distance qui m'intéresse: je ne sais jamais quand une envie de rebuilder Android AOSP peut me prendre, et ça marche qd même mieux sur le gros xeon avec les disques SAS et les 24Go de RAM :)
Sur un appareil full AOSP (donc sans les google apps, je ne sais pas si c'est le cas de Lineage), pas moyen de faire tourner airbnb, uber, wheely (équivalent russe à uber) etc…
Ces applications reposent trop sur les services google de localisation et de fond de carte, et donc sont inutilisables.
D'autres app (Waze, app de banque) ralent aussi sur l'absence des googles apps mais le fonctionnel reste maintenu.
Pour être 100% sur d'avoir accès à toutes les applis sans restriction, le scénario #2 semble le plus réaliste.
On parle de carte mère embarqué dans du serveur supermicro là … autant dire, du "cheap".
Les firewalls ont bien souvent du matos très "spécialisés" pour pouvoir faire leurs jobs vite sur un hard qui est loin d'être sur-performant (logique hein, si tu mets un xeon pour faire firewall, ça va pas le faire d'un point de vue conso elec, etc…).
D'ici à ce que les vilains chinois réussissent à compromettre du matos Cisco, Fortinet & co, je crois qu'on peut encore dormir sur nos deux oreilles.
Mais pour synthétiser, le secret réside dans:
Matrice de flux et firewalling précis et exhaustif.
Filtrage par du firewall "hardware".
Isolation par VLAN via du switch "hardware" de marque différente du firewall.
Eventuellement, second firewall d'une marque différente du premier pour filtrer les flux issus du premier.
Après, c'est sur que si le contrôle du hard est totale (dans l'hypothèse ou tout le monde se serait fait p0wn par les puces chinoises) bein on est foutu…
Pour ta question, je ne pense pas qu'il y ai de problème.
Tu as fait une image de ton disque, elle devrait s'appliquer sans soucis à ce même disque.
Fais par contre attention à ce qu'il n'y ai pas de différence sur le paramètre bs (blocksize) entre les deux dd utilisés, ça pourrait hypothétiquement mettre le bordel.
Sinon, en bonus, une petite astuce pour pouvoir compresser de façon optimale tes fichiers d'image: il faut les remplir de zero !
Là, tu as lu tout les blocs de ton disque, bloc qui sont pour certains inutilisés mais initialisés avec des valeurs "aléatoires": fatalement un compresseur va également passé sur ces octets totalement inutiles puisqu'il ne travaille pas au niveau FS.
Si tu veux pouvoir compresser un maximum tes images, alors, avant ton dd (ou après, en montant tes fichiers images), remplis ton image de zero à coup de
dd if=/dev/zero of=/zerofile
dd s'arrêtera tout seul quand il aura épuisé l'espace et tu pourras ensuite compresser fortement tes images sans soucis.
Le but n'est pas de protéger la machine mais les datas :)
Et donc je persiste… avec un partitionnement intelligent (/home séparé et, sur un serveur de prod, /srv || /opt || /data séparés), nul besoin de crypter l'intégralité du disque, et surtout pas /, puisque c'est du pur "standard".
Ce que je dis reste vrai.
Si:
* Ton serveur n'est accessible depuis l'extérieur que pour ses services officiels (serveur web/ftp/smtp/whatever).
* Ton serveur ne peut pas sortir de ton infra excepté pour répondre à ses services officiels.
Une prise de contrôle est quasi impossible.
En outre, dans les hypothèses que tu emets impliquent savoir que tel service est hébergé par un serveur compromis par la vilaine puce… compliqué, encore plus aujourd'hui à l'ère de la VM et des hyperviseurs …
Bien souvent, les serveurs physiques ne servent plus qu'à faire des tourner des machines virtuelles.
Je persiste à croire que ce genre d'attaque est inefficace sur une infra bien configurée.
Je mitigerais cette news très alarmiste en rappelant que, pour toute infrastructure un minimum sérieuse, on doit:
Etablir une matrice de flux pour :
Les différents serveurs entre eux.
Les différents serveurs vers l'extérieur.
Filtrer les flux réseaux en appliquant la politique du "Deny by default" et n'ouvrir que les flux qui sont référencés dans la matrice de flux.
Si ces deux points sont respectés, alors la puce chinoise ne servira pas à grand chose.
Un serveur n'est pas sensé faire des requêtes HTTP vers l'extérieur sauf pour ses updates (mais bien souvent, les grosses infras disposent de proxy pour ça).
Le seul covert channel qui serait réellement indécelable serait, éventuellement, de passer par des requêtes DNS… mais je doute que les chinois aient poussé le vice jusque là.
Chiffrer l'entièreté permet de rendre complètement inutilisable le système
Je vois pas trop l'intérêt… dans le cas d'une machine volée, de toutes façons, même si le cambrioleur/receleur/acheteur est utilisateur de Linux, il ré-installera la machine.
ainsi que les mariadb,
Je ne sais pas ou sont stockées les DB maria … mais rien ne t'empêche de faire
mkdir ~/mariadb/
ln -s ~/mariadb/
Et tes DB sont chiffrées aussi.
les fichiers de confs etc
Encore une fois, intérêt quasi nul à moins que tu aies des certificats ou clefs stockées dans /etc/.
Mais, encore une fois, cela peut se solutionner facilement en customisant des configs ou à coup de lien symboliques.
Tu es libre de faire comme tu veux, et de perdre des perfs si cela te chante.
Après, je peux aussi comprendre que tu veuilles le faire "pour le fun" :-)
Ton site pique les yeux. Vraiment, ça en donne aucune envie de lire ou de contribuer à ton article.
La formulation "Donc ce thread traite de la possibilité de chiffrer les partitions, dont surtout celle système. Le montage des partitions chiffrées se faisant via une commande SSH la plus standardisée possible (en vue de son automatisation)." porte à confusion: on a l'impression que tu veux chiffrer ton FS avec SSH. Il faudrait plus parler de "rentrer la passphrase via une commande SSH".
Qu'attends tu précisément sur la partie "Questions": qu'on aille lire ton site, et qu'on réponde là bas ? (sans moi). Qu'on réponde ici ?. Bon, je me lance ici:
Globalement un filesystem sur du stockage *SD, c'est pas la panacée: il faut s'assurer de réduire au maximum les écritures, mettre du noatime, etc… Il y a énormément de retour d'expérience sur ce sujet et ils sont globalement assez négatif. Une eMMC résistera à priori mieux.
Tout est possible … Mais ici, cela dépend
du taux d'utilisation de ton filesystem
de l'importance des données qui y sont stockées.
du partitionnement: dans un cas idéal, tu utilises LVM, tu réduis au strict minimum la taille du volume "en clair", tu crées un second volume chiffré, et tu migres ton contenu. Dans le cas d'une utilisation du disque en direct sans la couche LVM, ça va être un poil plus complexe (utilisation d'un disque externe temporairement).
A chaud ça risque d'être plus compliqué, un reboot au minimum sera nécessaire pour être "propre" et t'assurer que ta machine ne sera pas en carafe au prochain reboot, surtout que, loi d'emmerdement maximum, ce reboot aura lieu à cause d'EDF 6 mois après tes bidouilles et tu auras tout oublié ;-)
Les performances seront bien évidemment impactées. L'impact sera plus ou moins violent en fonction de ton hardware, de la présence (et le support correct par le noyau) d'un chip d'accélération crypto, etc…
Personnellement, j'opterai plus pour un système "en clair" et un /home chiffré…
À part qu'ils prennent une place pour voiture par moto.
Un motard est un usager de la route comme un autre, il a le droit à la même "place" que les autres.
Sinon, va falloir faire des 1/3 de places pour les smart, des places et demi pour les gros SUV…
Que quand ils ne le font pas c'est pour se garer sur la seule portion de trottoir disponible pour que les enfants circulent ailleurs qu'à trois centimètres des voitures.
Qu'ils font rugir le moteur au milieu du village.
Mmmwai. Et donc les "geeks" sont tous des puceaux boutonneux handicapés émotionnellement ? Les cathos tous des gros coincés qui ont un enfant par coït ?
Qu'une moto seule fait plus trembler les murs qu'un semi-remorque.
Pour avoir eu, pendant 1 an et demi, un appart qui était juste au dessus d'un feu rouge, je peux t'assurer que les motos ne faisait rien trembler.
Par contre les bus faisaient trembler mon évier et tout le reste…
Mais on s'en fout, c'est "responsable" le bus…
Et que « Mais comment peut-on prétendre apprécier la nature en roulant à travers à toute berzingue en faisant un bruit à faire fuir les fourmis, et en gazant toute vie à 1km à la ronde ? »
Tu parles de moto cross ou de trail ?
Cette réponse a beau tenter de se la jouer "troll du dredi", je sens quand même la rage du motard palpable.
C'est dommage, surtout venant de gens sensés être tolérant, sur le partage, etc…
Petite anecdote: il y a qq années (avant l'appart au dessus du feu rouge), j'allais régulièrement promener mon chien "en colline".
Je voyais beaucoup d'emballage de boissons énergisantes et de barres chocolatées du même acabit: ce n'est ni les promeneurs, ni les chasseurs et encore moins les adeptes de moto trail qui consomment ce genre de merde, mais bien les randonneurs.
Des connards qui ne respectent rien, y en a malheureusement partout.
Je trouve ce projet au top.
Par contre, je pense qu'il gagnerait à être rendu plus générique !
Aujourd'hui tu cibles les randonneurs, mais il y a tout un tas de profil de "vadrouilleurs" qui pourrait être friands de ce genre de service:
Les motards qui débarquent en vacances dans un coin et cherchent les plus jolies balades et des roadtrips détaillés.
Les voyageurs plus lambda qui cherchent des points d'intérêt autour de leurs lieux de villégiatures.
Les voyageurs qui font du camping sauvage qui cherchent le spot le plus meugnon ou prendre le ptit dej au cul du fourgon (park4night existe sur ce domaine, mais je le trouve un poil trop pauvre, leurs site est d'une lourdeur rare, et l'appli mobile inutilisable sur un téléphone AOSP).
Et j'en oublie certainement…
Super boulot en tout cas!
J'ajouterai que ce n'est pas parce que tu vas installer une distribution généraliste que tu ne pourras la doter après coup de tout les outils de sécurité qui vont bien.
Une distribution reste, basiquement, un noyau linux, et un user-land "choisi". Tu peux ensuite étendre ce user-land par le biais de paquets non officiels ou en compilant toi même les outils que tu souhaites utiliser.
Totalement d'accord avec ce commentaire.
Ton scanner doit déjà intégrer un mode "multi-passe" pour sa qualité maximale.
Rajouter des passes ne servira a rien si ce n'est à te compliquer ta vie et, peut être, avoir un résultat encore plus pourri.
Vu la teneur de la question je vais présumer que:
_ Tu parles de ton desktop.
_ Tu parles de panne "logicielle".
_ Tu es "relativement" débutant.
Sache tout d'abord que les pannes logicielles nécessitant la réinstallation complète d'une debian sont rares … très rares.
Cependant, je ne pense pas que, dans ce contexte précis, une réinstallation du système soit problématique… au contraire ;-)
Par contre, ce qu'il faut "sécuriser", c'est que ta réinstallation soit complète et, surtout, que tu ne perdes pas tes données.
Pour ne pas perdre tes données, utiliser une partition /home séparée est une bonne solution qui te permet de dissocier tes fichiers personnels de ceux du système.
Si tu installes beaucoup de paquet à la main vers /usr/local, ça peut être également une bonne chose de mettre cette arbo sur une partition dédiée.
Si tu as une configuration apache/Xorg/whatever aux petits oignons, c'est plutôt /etc qu'il faut chercher à protéger.
Pour finir, pour réinstaller un système à l'identique, tu régulièrement sauvegarder l'output d'un dpkg -l qui te listera les paquets installés sur ton système.
Sinon, il existe une multitude de solution pour faire des snapshots de ton système, du gros tar bourrin en passant par des solutions plus exotiques.
Mais là, ta question est trop vague pour qu'on puisse réellement t'aiguiller.
Le premier, qui intègre décodeur et HDD dans le même boitier (évolution je crois, ou révolution j'sais plus) est une bouze de la pire espèce: temps de zap infernaux, long que ça en peut plus.
Le second, plus récent, form factor en deux parties (boitier HDD à part) est bon. Temps de zap hyper rapide, et expérience utilisateur très très convenable.
Un bug pénible cependant: lorsque tu te sers de l'appli "radio web" puisque tu repasses en mode TV, entre chaque zap la box rebascule sur la radio… ça aurait pu être cool si il n'y avait pas une différence de niveau sonore significative entre la TV et la radio (la radio est beaucoup plus forte).
Puisque c'est bien souvent très localisé, je précise que j'ai eu d'abord un abo fibre chez eux dans le 8eme arrondissement de Marseille: rien à redire en terme de qualité de service, ça va vite et tout le temps. Le wifi était cependant un peu à la peine le soir venu dans ma résidence saturée d'ondes.
J'ai récemment déménagé à Six Fours et ça marche toujours aussi bien: 400Mbs en down, ~100 en up. Le wifi semble plus en forme, mais bon, il est le seul à rayonner dans les environs, ça aide.
Par contre, pour le reste de l'offre, leurs décodeur télé ancienne génération (large, format hi-fi) est une bouze infame avec des temps de zap de l'ordre de 5/6 secondes.
Lors de mon déménagement, j'ai demandé un décodeur nouvelle génération, tout est bien meilleur.
L'offre VOD illimité comprise dans mon abo est un poil pauvre: peu de films récents, peu de films vraiment bons.
[^] # Re: Jamais -e
Posté par LaBienPensanceMaTuer . En réponse au message Sortie flux > dans un dossier précis Cron. Évalué à 4.
Demain j'ouvre un compte "ManuMacron" et je suis le président? ;-)
Et d'ailleurs, il l'écrit et tu le cites: "il commence avec les tâches planifiées".
Il le redit d'ailleurs dans un commentaire un peu plus bas:
Et excuse moi, il me parait plus logique d'apprendre d'abord la méthode qui marche partout (aka crontab -e) avant de s'orienter vers les évolutions introduites par Linux et les *bsd, aka /etc/cron.{d,daily,weekly,monthly}
Pour finir sur le sujet cron, AdminSec est étudiant … à mon époque (pas si lointaine), on avait pas l'accès root au serveur utilisé pour les TP … tu fais comment sans crontab -e dans ce contexte, quand tu es un simple user ?
C'est comme les bashismes: perso, je conseillerai à un étudiant d'apprendre à correctement se servir de /bin/sh "de base" avant de s'envoyer sur les bashismes…
Pour continuer sur ton commentaire, dans un monde pro:
Tu versionnes correctement ces fichiers via git ou autre outil.
Tu commentes abondamment les modifications pour que tes co-admins aient l'historique.
Partant de ces deux "bonnes pratiques de base", je ne vois pas ce que ça change d'avoir 1 fichier par "tâche" VS 1 fichier pour toutes les tâches.
En outre, et toujours dans le monde pro:
N'oublie pas qu'avant d'être un pro, il faut connaitre "les bases".
# Utilise des chemins absolus
Posté par LaBienPensanceMaTuer . En réponse au message Sortie flux > dans un dossier précis Cron. Évalué à 3.
Salut,
Tes commandes sont executés dans le working directory de cron ce qui n'est pas l'effet souhaité.
Il faut plutôt utiliser des chemins absolus: plutôt que
./DistUpgradetu peux plutôt utiliser/home/<ton user>/<le rep de ton choix>/DistUpgradeet ce pour tout tes commandes.Si tu souhaites ne pas répéter ce chemin (et faire des erreurs au passage), tu peux déclarer une variable,
TARGET_DIR=/home/<ton user>/<le rep de ton choix>/DistUpgradepuis ensuite utiliser${TARGET_DIR}/DistUpgrade.[^] # Re: Jamais -e
Posté par LaBienPensanceMaTuer . En réponse au message Sortie flux > dans un dossier précis Cron. Évalué à 4.
Ca répond pas à ça question, et crontab -e, pour une utilisation "amateur" reste tout à fait adapté.
Sans compter qu'il n'est pas gagné que le /etc/cron.d soit implémenté sur toutes les distris et, surtout, sur les Unix.
Mauvais conseil, désolé…
[^] # Re: une idée à la con ?
Posté par LaBienPensanceMaTuer . En réponse au message Multiprise "connectée". Évalué à 2.
En effet, c'est du bon vieux Xeon.
Par contre, l'idée est de se baser autant que faire se peut sur du wifi (pas encore tiré le RJ partout …).
Je ne sais pas du tout si le WoL fonctionne sur du wifi …
[^] # Re: Weemo
Posté par LaBienPensanceMaTuer . En réponse au message Multiprise "connectée". Évalué à 2.
Intéressant, peut être la solution la plus simple…
[^] # Re: Si tu as les moyens ...
Posté par LaBienPensanceMaTuer . En réponse au message Multiprise "connectée". Évalué à 2.
Pouah, j'aurai bien aimé, mais le budget va pas suivre !
[^] # Re: jeedom compatible ?
Posté par LaBienPensanceMaTuer . En réponse au message Multiprise "connectée". Évalué à 2.
La solution peut me convenir, même si elle demande quand même un minimum de taf d'intégration …
Je vais quand même voir si il n'y a pas quelque chose de plus "plug-n-play", mais merci pour la piste !
[^] # Re: une idée à la con ?
Posté par LaBienPensanceMaTuer . En réponse au message Multiprise "connectée". Évalué à 2.
Le problème n'est pas tant d'éteindre le serveur (pour le coup un shutdown ou halt -p fait l'affaire), mais plus de le rallumer.
Une fonctionnalité intéressante des machines rackables ou plus généralement à vocation serveur, est leur capacité à s'allumer après un powercut.
C'est un allumage à distance qui m'intéresse: je ne sais jamais quand une envie de rebuilder Android AOSP peut me prendre, et ça marche qd même mieux sur le gros xeon avec les disques SAS et les 24Go de RAM :)
# Lors de mes derniers essais
Posté par LaBienPensanceMaTuer . En réponse au message téléphone sans google. Évalué à 2.
Sur un appareil full AOSP (donc sans les google apps, je ne sais pas si c'est le cas de Lineage), pas moyen de faire tourner airbnb, uber, wheely (équivalent russe à uber) etc…
Ces applications reposent trop sur les services google de localisation et de fond de carte, et donc sont inutilisables.
D'autres app (Waze, app de banque) ralent aussi sur l'absence des googles apps mais le fonctionnel reste maintenu.
Pour être 100% sur d'avoir accès à toutes les applis sans restriction, le scénario #2 semble le plus réaliste.
[^] # Re: Mitigeons....
Posté par LaBienPensanceMaTuer . En réponse au journal Des puces-espionnes installées sur des cartes mères par les Chinois ?. Évalué à 2.
On parle de carte mère embarqué dans du serveur supermicro là … autant dire, du "cheap".
Les firewalls ont bien souvent du matos très "spécialisés" pour pouvoir faire leurs jobs vite sur un hard qui est loin d'être sur-performant (logique hein, si tu mets un xeon pour faire firewall, ça va pas le faire d'un point de vue conso elec, etc…).
D'ici à ce que les vilains chinois réussissent à compromettre du matos Cisco, Fortinet & co, je crois qu'on peut encore dormir sur nos deux oreilles.
Mais pour synthétiser, le secret réside dans:
Matrice de flux et firewalling précis et exhaustif.
Filtrage par du firewall "hardware".
Isolation par VLAN via du switch "hardware" de marque différente du firewall.
Eventuellement, second firewall d'une marque différente du premier pour filtrer les flux issus du premier.
Après, c'est sur que si le contrôle du hard est totale (dans l'hypothèse ou tout le monde se serait fait p0wn par les puces chinoises) bein on est foutu…
# Astuce compression...
Posté par LaBienPensanceMaTuer . En réponse au message Copie de disque dur et carte SD. Évalué à 4.
Pour ta question, je ne pense pas qu'il y ai de problème.
Tu as fait une image de ton disque, elle devrait s'appliquer sans soucis à ce même disque.
Fais par contre attention à ce qu'il n'y ai pas de différence sur le paramètre bs (blocksize) entre les deux dd utilisés, ça pourrait hypothétiquement mettre le bordel.
Sinon, en bonus, une petite astuce pour pouvoir compresser de façon optimale tes fichiers d'image: il faut les remplir de zero !
Là, tu as lu tout les blocs de ton disque, bloc qui sont pour certains inutilisés mais initialisés avec des valeurs "aléatoires": fatalement un compresseur va également passé sur ces octets totalement inutiles puisqu'il ne travaille pas au niveau FS.
Si tu veux pouvoir compresser un maximum tes images, alors, avant ton dd (ou après, en montant tes fichiers images), remplis ton image de zero à coup de
dd if=/dev/zero of=/zerofile
dd s'arrêtera tout seul quand il aura épuisé l'espace et tu pourras ensuite compresser fortement tes images sans soucis.
[^] # Re: Mon retour....
Posté par LaBienPensanceMaTuer . En réponse au message [WorkFlow] [Ubuntu/Debian] Chiffrer ses partitions avec montage via commande SSH. Évalué à 3.
Et donc je persiste… avec un partitionnement intelligent (/home séparé et, sur un serveur de prod, /srv || /opt || /data séparés), nul besoin de crypter l'intégralité du disque, et surtout pas /, puisque c'est du pur "standard".
[^] # Re: Mitigeons....
Posté par LaBienPensanceMaTuer . En réponse au journal Des puces-espionnes installées sur des cartes mères par les Chinois ?. Évalué à 3. Dernière modification le 05 octobre 2018 à 15:01.
Ce que je dis reste vrai.
Si:
* Ton serveur n'est accessible depuis l'extérieur que pour ses services officiels (serveur web/ftp/smtp/whatever).
* Ton serveur ne peut pas sortir de ton infra excepté pour répondre à ses services officiels.
Une prise de contrôle est quasi impossible.
En outre, dans les hypothèses que tu emets impliquent savoir que tel service est hébergé par un serveur compromis par la vilaine puce… compliqué, encore plus aujourd'hui à l'ère de la VM et des hyperviseurs …
Bien souvent, les serveurs physiques ne servent plus qu'à faire des tourner des machines virtuelles.
Je persiste à croire que ce genre d'attaque est inefficace sur une infra bien configurée.
[^] # Re: Mitigeons....
Posté par LaBienPensanceMaTuer . En réponse au journal Des puces-espionnes installées sur des cartes mères par les Chinois ?. Évalué à 2.
Tout le secret ici est de faire les filtrages en aval des serveurs: firewall, passerelles, etc…
# Mitigeons....
Posté par LaBienPensanceMaTuer . En réponse au journal Des puces-espionnes installées sur des cartes mères par les Chinois ?. Évalué à 2.
Je mitigerais cette news très alarmiste en rappelant que, pour toute infrastructure un minimum sérieuse, on doit:
Etablir une matrice de flux pour :
Filtrer les flux réseaux en appliquant la politique du "Deny by default" et n'ouvrir que les flux qui sont référencés dans la matrice de flux.
Si ces deux points sont respectés, alors la puce chinoise ne servira pas à grand chose.
Un serveur n'est pas sensé faire des requêtes HTTP vers l'extérieur sauf pour ses updates (mais bien souvent, les grosses infras disposent de proxy pour ça).
Le seul covert channel qui serait réellement indécelable serait, éventuellement, de passer par des requêtes DNS… mais je doute que les chinois aient poussé le vice jusque là.
[^] # Re: Mon retour....
Posté par LaBienPensanceMaTuer . En réponse au message [WorkFlow] [Ubuntu/Debian] Chiffrer ses partitions avec montage via commande SSH. Évalué à 3.
Je vois pas trop l'intérêt… dans le cas d'une machine volée, de toutes façons, même si le cambrioleur/receleur/acheteur est utilisateur de Linux, il ré-installera la machine.
Je ne sais pas ou sont stockées les DB maria … mais rien ne t'empêche de faire
mkdir ~/mariadb/
ln -s ~/mariadb/
Et tes DB sont chiffrées aussi.
Encore une fois, intérêt quasi nul à moins que tu aies des certificats ou clefs stockées dans /etc/.
Mais, encore une fois, cela peut se solutionner facilement en customisant des configs ou à coup de lien symboliques.
Tu es libre de faire comme tu veux, et de perdre des perfs si cela te chante.
Après, je peux aussi comprendre que tu veuilles le faire "pour le fun" :-)
# Mon retour....
Posté par LaBienPensanceMaTuer . En réponse au message [WorkFlow] [Ubuntu/Debian] Chiffrer ses partitions avec montage via commande SSH. Évalué à 5.
Ton site pique les yeux. Vraiment, ça en donne aucune envie de lire ou de contribuer à ton article.
La formulation "Donc ce thread traite de la possibilité de chiffrer les partitions, dont surtout celle système. Le montage des partitions chiffrées se faisant via une commande SSH la plus standardisée possible (en vue de son automatisation)." porte à confusion: on a l'impression que tu veux chiffrer ton FS avec SSH. Il faudrait plus parler de "rentrer la passphrase via une commande SSH".
Qu'attends tu précisément sur la partie "Questions": qu'on aille lire ton site, et qu'on réponde là bas ? (sans moi). Qu'on réponde ici ?. Bon, je me lance ici:
Personnellement, j'opterai plus pour un système "en clair" et un /home chiffré…
[^] # Re: Chouette projet qui mériterait d'être plus "générique"
Posté par LaBienPensanceMaTuer . En réponse au journal EnVadrouille, une galerie photo pour vos randos (5 ans après). Évalué à -1. Dernière modification le 28 septembre 2018 à 11:31.
Un motard est un usager de la route comme un autre, il a le droit à la même "place" que les autres.
Sinon, va falloir faire des 1/3 de places pour les smart, des places et demi pour les gros SUV…
Mmmwai. Et donc les "geeks" sont tous des puceaux boutonneux handicapés émotionnellement ? Les cathos tous des gros coincés qui ont un enfant par coït ?
Pour avoir eu, pendant 1 an et demi, un appart qui était juste au dessus d'un feu rouge, je peux t'assurer que les motos ne faisait rien trembler.
Par contre les bus faisaient trembler mon évier et tout le reste…
Mais on s'en fout, c'est "responsable" le bus…
Cette réponse a beau tenter de se la jouer "troll du dredi", je sens quand même la rage du motard palpable.
C'est dommage, surtout venant de gens sensés être tolérant, sur le partage, etc…
Petite anecdote: il y a qq années (avant l'appart au dessus du feu rouge), j'allais régulièrement promener mon chien "en colline".
Je voyais beaucoup d'emballage de boissons énergisantes et de barres chocolatées du même acabit: ce n'est ni les promeneurs, ni les chasseurs et encore moins les adeptes de moto trail qui consomment ce genre de merde, mais bien les randonneurs.
Des connards qui ne respectent rien, y en a malheureusement partout.
allé, bisous !
# Chouette projet qui mériterait d'être plus "générique"
Posté par LaBienPensanceMaTuer . En réponse au journal EnVadrouille, une galerie photo pour vos randos (5 ans après). Évalué à 7.
Je trouve ce projet au top.
Par contre, je pense qu'il gagnerait à être rendu plus générique !
Aujourd'hui tu cibles les randonneurs, mais il y a tout un tas de profil de "vadrouilleurs" qui pourrait être friands de ce genre de service:
Les motards qui débarquent en vacances dans un coin et cherchent les plus jolies balades et des roadtrips détaillés.
Les voyageurs plus lambda qui cherchent des points d'intérêt autour de leurs lieux de villégiatures.
Les voyageurs qui font du camping sauvage qui cherchent le spot le plus meugnon ou prendre le ptit dej au cul du fourgon (park4night existe sur ce domaine, mais je le trouve un poil trop pauvre, leurs site est d'une lourdeur rare, et l'appli mobile inutilisable sur un téléphone AOSP).
Et j'en oublie certainement…
Super boulot en tout cas!
[^] # Re: Commencer doucement
Posté par LaBienPensanceMaTuer . En réponse au message choix Linux. Évalué à 4.
J'ajouterai que ce n'est pas parce que tu vas installer une distribution généraliste que tu ne pourras la doter après coup de tout les outils de sécurité qui vont bien.
Une distribution reste, basiquement, un noyau linux, et un user-land "choisi". Tu peux ensuite étendre ce user-land par le biais de paquets non officiels ou en compilant toi même les outils que tu souhaites utiliser.
[^] # Re: Bouillie
Posté par LaBienPensanceMaTuer . En réponse au message Reconstituer une belle image à partir de plusieurs scans médiocres. Évalué à 5.
Totalement d'accord avec ce commentaire.
Ton scanner doit déjà intégrer un mode "multi-passe" pour sa qualité maximale.
Rajouter des passes ne servira a rien si ce n'est à te compliquer ta vie et, peut être, avoir un résultat encore plus pourri.
# Ailleurs sur le web
Posté par LaBienPensanceMaTuer . En réponse au message Thinkpad x230t: rotation de l'écran et stylet. Évalué à 3.
D'autres se sont posés la question, et y ont trouvé une réponse:
https://ubuntuforums.org/showthread.php?t=943297
C'est peut être pas tout à fait le même matos, mais ça devrait t'aiguiller.
Il y a aussi un xsetwacom qui semble exister et qui a une commande "rotate":
https://github.com/linuxwacom/xf86-input-wacom/wiki/xsetwacom
Tout ça, c'est google qui me l'a dit …
# Mon point de vue...
Posté par LaBienPensanceMaTuer . En réponse au message Quelles précautions pour ne pas réinstaller tous le système linux en cas de panne. Évalué à 5.
Vu la teneur de la question je vais présumer que:
_ Tu parles de ton desktop.
_ Tu parles de panne "logicielle".
_ Tu es "relativement" débutant.
Sache tout d'abord que les pannes logicielles nécessitant la réinstallation complète d'une debian sont rares … très rares.
Cependant, je ne pense pas que, dans ce contexte précis, une réinstallation du système soit problématique… au contraire ;-)
Par contre, ce qu'il faut "sécuriser", c'est que ta réinstallation soit complète et, surtout, que tu ne perdes pas tes données.
Pour ne pas perdre tes données, utiliser une partition /home séparée est une bonne solution qui te permet de dissocier tes fichiers personnels de ceux du système.
Si tu installes beaucoup de paquet à la main vers /usr/local, ça peut être également une bonne chose de mettre cette arbo sur une partition dédiée.
Si tu as une configuration apache/Xorg/whatever aux petits oignons, c'est plutôt /etc qu'il faut chercher à protéger.
Pour finir, pour réinstaller un système à l'identique, tu régulièrement sauvegarder l'output d'un dpkg -l qui te listera les paquets installés sur ton système.
Sinon, il existe une multitude de solution pour faire des snapshots de ton système, du gros tar bourrin en passant par des solutions plus exotiques.
Mais là, ta question est trop vague pour qu'on puisse réellement t'aiguiller.
[^] # Re: Box TV
Posté par LaBienPensanceMaTuer . En réponse au message Retour sur Red by SFR. Évalué à 3.
T'as deux décodeurs:
Le premier, qui intègre décodeur et HDD dans le même boitier (évolution je crois, ou révolution j'sais plus) est une bouze de la pire espèce: temps de zap infernaux, long que ça en peut plus.
Le second, plus récent, form factor en deux parties (boitier HDD à part) est bon. Temps de zap hyper rapide, et expérience utilisateur très très convenable.
Un bug pénible cependant: lorsque tu te sers de l'appli "radio web" puisque tu repasses en mode TV, entre chaque zap la box rebascule sur la radio… ça aurait pu être cool si il n'y avait pas une différence de niveau sonore significative entre la TV et la radio (la radio est beaucoup plus forte).
# Retour Red By SFR PACA
Posté par LaBienPensanceMaTuer . En réponse au message Retour sur Red by SFR. Évalué à 3.
Puisque c'est bien souvent très localisé, je précise que j'ai eu d'abord un abo fibre chez eux dans le 8eme arrondissement de Marseille: rien à redire en terme de qualité de service, ça va vite et tout le temps. Le wifi était cependant un peu à la peine le soir venu dans ma résidence saturée d'ondes.
J'ai récemment déménagé à Six Fours et ça marche toujours aussi bien: 400Mbs en down, ~100 en up. Le wifi semble plus en forme, mais bon, il est le seul à rayonner dans les environs, ça aide.
Par contre, pour le reste de l'offre, leurs décodeur télé ancienne génération (large, format hi-fi) est une bouze infame avec des temps de zap de l'ordre de 5/6 secondes.
Lors de mon déménagement, j'ai demandé un décodeur nouvelle génération, tout est bien meilleur.
L'offre VOD illimité comprise dans mon abo est un poil pauvre: peu de films récents, peu de films vraiment bons.