J'avais déjà entendu parlé de Bacula mais je ne l'ai jamais testé, sinon j'imagine que cela s'interfacera facilement dans un bon petit script bash avec du cron du md5 et la sauvegarde est ok :)
Bacula ? Non non, bacula est un logiciel de sauvegarde sur bande totalement intégré. Il ne s'interface avec rien du tout et gère lui même ses questions d'intégrité et de résultat des backups.
Pour bacula tu as :
un (des) serveurs gérant le stockage (sur bande ou bande virtuelle sur disque)
un serveur gérant la base de données
un agent qui tourne sur les serveurs à backuper
un backula-director qui donne les ordres aux agents et aux storages pour que tout ce joli monde communique.
Pour moi le problème majeur est :
- Du fait de la structure séquentielle des backups (bandes), le temps de restauration est très long.
- C'est clairement une usine à gaz en particulier à cause du stockage des informations en base de données (Tel fichier de telle machine à telle date est sur telle bande à telle position).
Pour moi bacula est beaucoup plus adapté à de l'archivage de données qu'à du backup opérationnel. Quand il faut remonter une machine à partir d'un backup bacula, c'est l'angoisse.
Ils sont plussés parcequ'ils sont drôles, provocants et interpellent.
Comme tu le dis toi même il s'agit de plussage et de moinssage. La cosmétique (pertinent / inutile) n'y changera rien.
Le concept de plussage/moinssage englobe le "c'est intéressant", "c'est drôle", "t'es mon coping", "je suis pas d'accord", "t'es qu'un boulet", "j'ai un petit compte à régler", "c'est vendredi" et bien d'autre notions subjectives et épiphénomènes culturels façon Zino et PanPan CoinCoin.
Tout ça étant bien antérieur au [J'aime] de facebook et aux efforts désespérés de certains pour faire de ce site un endroit sérieux.
Si ton hébergeur propose la config suivante :
- apache exécuté sous une identité différente du propriétaire des fichiers (nobody, www, www-data …)
- php exécuté sous l’identité du propriétaire des fichiers
Alors les bonnes permissions son 711(rwx--x--x) pour les dossiers, 600 pour les fichiers php et 644 pour les fichiers statiques. Sauf si apache et ton utilisateur partagent le même groupe (ce qui de-facto ne change rien vu qu'alors il est probable que tous les autres utilisateurs le partagent aussi). Dans ce cas tu peux faire 710, 600, 640.
Cela évitera que n'importe qui ne liste le contenu des répertoires. Par contre le mode auto-index d'apache ne marchera plus.
Comment ça se fait qu'on entende encore parlé d'OSS alors qu'Alsa déjà à son époque devait en grande partie le remplacer ?
On entend encore parler d'OSS car c'est un standard de fait dans le monde Unix et en particulier Solaris qui est largement utilisé dans les traitements numériques lourds (cinéma notamment). Linux est me semble-t-il le seul Unix Like a utiliser un système différent.
Est-ce que les développeurs de ces libs font de l'intégrisme/chauvinisme ou est-ce que je loupe qq chose ?
Les pilotes OSSv4 sont produits par 4front une boite spécialisé dans les cartes son. Il sont largement portable et utilisés dans l'industrie (je suppute que 4front fait son beurre en vendant des licences pour des OS proprios ou de l'embarqué). Je ne pense pas que ce soit le support de linux qui les fasse vivre, mais c'est quand même sympa de le faire.
Mais si tu veux du pas chère, il y a le Raspberry Pi. L'OS OpenElec le support.
Oui enfin c'est quand même relativement expérimental encore. Hors des videos accélérés l'interface rame pas mal (sans doute à cause de SDL) ainsi que tout ce qui a besoin de cpu. Clairement XBMC sur un Raspberry Pi est possible, mais à condition d'avoir un serveur de base de données déporté, le thème le plus léger qui soit et peu d'addons. Par exemple Boblight n'arrive pas à suivre.
Je propose la licence. SVN est sous licence Apache/BSD et Git sous GPL.
En partie mais pas seulement. En réalité le choix de svn a été il y a longtemps pour diverses raisons. L'arbre des ports était encore sous cvs car personne ne s'en était occupé tout simplement.
La principale de ses raisons est que pour l'heure, la distribution des sources et de l'arbre des ports se fait en utilisant csup qui est un outil basé sur cvs extrêmement rapide. Il existe donc toujours un dépot cvs qui est synchronisé automatiquement avec le svn et qui est sollicité de façon intensive. Sous FreeBSD l'utilisation des sources reste le moyen privilégié de faire ses mises à jour. Il s'agit donc d'une brique essentielle de l'infrastructure du projet, pour les développeurs certes mais aussi pour l'ensemble des serveurs en production.
De plus autour du svn de FreeBSD il y a de nombreux outils qu'il serait long et laborieux d'adapter. Enfin dans la structure même du projet, ses traditions, ses meurs, l'aspect centralisé est extrêmement important. Très peu de personnes commitent.
La question d'un passage à git a été débattue (vivement). Il a été décidé qu'il y aurait des miroirs git officiel (ainsi qu'un mirroir hg) :
svn n'est pas forcément le meilleurs gestionnaire de sources. Mais il permet de garder la rétro compatibilité avec CVS et surtout csup ainsi que d'utiliser git et hg.
Ou vois-tu de bonnes choses ? La commission règle ici une question de concurrence. Cela ne changera strictement rien au fond du problème qui est que quoiqu'il en soit ce que tu achètes est un droit d'utilisation limité et pas une copie de l'oeuvre.
Ça me fait vraiment penser à quelqu'un qui astique les cuivres alors que le bateau coule ; une mesurette sans ambition de plus dans un contexte étriqué et bureaucratique. Putain on serait en droit d'attendre des choses plus ambitieuses que le règlement de petites gueguerres entre majors. La commission traite l'économie numérique comme elle a traité l'industrie et l'agriculture ; par le petit bout de la lorgnette. Gageons que le résultat sera à la hauteur.
Moi je dis Supaire ! Chouette ! Au point ou nous en sommes, je trouve qu'on devrait instaurer une minute quotidienne obligatoire pour applaudir aux décisions de la Commission. Et que j'entende bien les 11 millions de Grecs applaudir avec moi.
Ou pas. Je dirais que ça marche globalement bien mais il ne faut pas oublier de faire un test du jeu de backup. Je eu quelques problèmes sur les bases > à 20 GO en particulier lorsque l'innodb_file_per_table n'est pas activé. L'heure est également extrêmement importante si on stream sur le réseau.
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.
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.
Le gros algo automatique pourrait être le cas d'erreur, en cas de grosse panique, histoire de gagner qq heures d'uptime ?
Je ne suis pas sûr que le gros du downtime soit lié au protocole lui même ou a des erreurs d’architecture. Le dogme veut que les annonces soient faites par les routeurs de bordure. Du coup combien de routeurs continent d'annoncer des routes qu'ils n'ont plus (typiquement routeur à th2 serveurs à Courbevoie, lien th2 / Courbevoie tombé). Ce problème s'évite pourtant très simplement en faisant les annonces depuis Courbevoie et en les relayant à th2. Mais c'est contre le dogme.
Pareillement l'injection d'une route par défaut en dur dans le noyau permet d'éviter les pannes en cas de plantage des daemon de routage.
Enfin en général les gens essayent de tout faire passer par un ou deux énormes routeurs proprios alors qu'en divisant astucieusement leur réseau ils pourraient se contenter d'équipements plus légers, plus divers et minimiser l'impact des pannes.
Je ne suis pas expert mais je pense qu'a la base des grandes pannes, il y a toujours une erreur d'architecture ou un manque de diversité. Le protocole est secondaire.
[^] # Re: Merci
Posté par Joris Dedieu (site web personnel) . En réponse au journal Le principe KISS appliqué à la gestion des sauvegardes.. Évalué à 8.
Bacula ? Non non, bacula est un logiciel de sauvegarde sur bande totalement intégré. Il ne s'interface avec rien du tout et gère lui même ses questions d'intégrité et de résultat des backups.
Pour bacula tu as :
Pour moi le problème majeur est :
- Du fait de la structure séquentielle des backups (bandes), le temps de restauration est très long.
- C'est clairement une usine à gaz en particulier à cause du stockage des informations en base de données (Tel fichier de telle machine à telle date est sur telle bande à telle position).
Pour moi bacula est beaucoup plus adapté à de l'archivage de données qu'à du backup opérationnel. Quand il faut remonter une machine à partir d'un backup bacula, c'est l'angoisse.
[^] # Re: Pour info
Posté par Joris Dedieu (site web personnel) . En réponse au journal Les commentaires LinuxFr.org insultants, nauséabonds ou illégaux les mieux notés. Évalué à 6.
Comme tu le dis toi même il s'agit de plussage et de moinssage. La cosmétique (pertinent / inutile) n'y changera rien.
Le concept de plussage/moinssage englobe le "c'est intéressant", "c'est drôle", "t'es mon coping", "je suis pas d'accord", "t'es qu'un boulet", "j'ai un petit compte à régler", "c'est vendredi" et bien d'autre notions subjectives et épiphénomènes culturels façon Zino et PanPan CoinCoin.
Tout ça étant bien antérieur au [J'aime] de facebook et aux efforts désespérés de certains pour faire de ce site un endroit sérieux.
[^] # Re: Réponse évidente
Posté par Joris Dedieu (site web personnel) . En réponse au journal Dans le Claude. Évalué à 1.
J'achèterai un Ipad
[^] # Re: Lumiere, Lumiere
Posté par Joris Dedieu (site web personnel) . En réponse au journal fr.misc.cryptologie. Évalué à 5.
Même pas. C'est un site perso chez alice affiché dans une frame.
# Pourquoi 755 ou 750 ?
Posté par Joris Dedieu (site web personnel) . En réponse au message changer les permission de tous les dossiers. Évalué à 2.
Si ton hébergeur propose la config suivante :
- apache exécuté sous une identité différente du propriétaire des fichiers (nobody, www, www-data …)
- php exécuté sous l’identité du propriétaire des fichiers
Alors les bonnes permissions son 711(rwx--x--x) pour les dossiers, 600 pour les fichiers php et 644 pour les fichiers statiques. Sauf si apache et ton utilisateur partagent le même groupe (ce qui de-facto ne change rien vu qu'alors il est probable que tous les autres utilisateurs le partagent aussi). Dans ce cas tu peux faire 710, 600, 640.
Cela évitera que n'importe qui ne liste le contenu des répertoires. Par contre le mode auto-index d'apache ne marchera plus.
[^] # Re: A fond
Posté par Joris Dedieu (site web personnel) . En réponse au journal La fin de la vue en arborescence dans Nautilus ?. Évalué à 2.
pkgng est dans head. Donc c'est bien partie.
http://svnweb.freebsd.org/base/head/usr.sbin/pkg/
[^] # Re: Si tu reboot une fois par an ça va !
Posté par Joris Dedieu (site web personnel) . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à 3.
très utile pour du firewalling applicatif. Il existe même des moteurs de regex implémentés en hard dans certaines appliance proprio.
[^] # Re: Excusez moi mais…
Posté par Joris Dedieu (site web personnel) . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à 4.
Et toi, tu tu manques cruellement d'humour.
[^] # Re: Excusez moi mais…
Posté par Joris Dedieu (site web personnel) . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à 3.
man 3 exec[^] # Re: son
Posté par Joris Dedieu (site web personnel) . En réponse au journal Linux a des défauts sur le bureau. Évalué à 4.
On entend encore parler d'OSS car c'est un standard de fait dans le monde Unix et en particulier Solaris qui est largement utilisé dans les traitements numériques lourds (cinéma notamment). Linux est me semble-t-il le seul Unix Like a utiliser un système différent.
Les pilotes OSSv4 sont produits par 4front une boite spécialisé dans les cartes son. Il sont largement portable et utilisés dans l'industrie (je suppute que 4front fait son beurre en vendant des licences pour des OS proprios ou de l'embarqué). Je ne pense pas que ce soit le support de linux qui les fasse vivre, mais c'est quand même sympa de le faire.
[^] # Re: Processeur Intel fanless
Posté par Joris Dedieu (site web personnel) . En réponse au journal XBMC sur allwinner A10. Évalué à 2.
Oui enfin c'est quand même relativement expérimental encore. Hors des videos accélérés l'interface rame pas mal (sans doute à cause de SDL) ainsi que tout ce qui a besoin de cpu. Clairement XBMC sur un Raspberry Pi est possible, mais à condition d'avoir un serveur de base de données déporté, le thème le plus léger qui soit et peu d'addons. Par exemple Boblight n'arrive pas à suivre.
[^] # Re: SVN vs Git
Posté par Joris Dedieu (site web personnel) . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 5.
En partie mais pas seulement. En réalité le choix de svn a été il y a longtemps pour diverses raisons. L'arbre des ports était encore sous cvs car personne ne s'en était occupé tout simplement.
La principale de ses raisons est que pour l'heure, la distribution des sources et de l'arbre des ports se fait en utilisant csup qui est un outil basé sur cvs extrêmement rapide. Il existe donc toujours un dépot cvs qui est synchronisé automatiquement avec le svn et qui est sollicité de façon intensive. Sous FreeBSD l'utilisation des sources reste le moyen privilégié de faire ses mises à jour. Il s'agit donc d'une brique essentielle de l'infrastructure du projet, pour les développeurs certes mais aussi pour l'ensemble des serveurs en production.
De plus autour du svn de FreeBSD il y a de nombreux outils qu'il serait long et laborieux d'adapter. Enfin dans la structure même du projet, ses traditions, ses meurs, l'aspect centralisé est extrêmement important. Très peu de personnes commitent.
La question d'un passage à git a été débattue (vivement). Il a été décidé qu'il y aurait des miroirs git officiel (ainsi qu'un mirroir hg) :
git://git.freebsd.your.org/freebsd-head
rsync://repos.freebsd.your.org/freebsd-head.git/
git://github.com/freebsd/freebsd-head.git
git://gitorious.org/freebsd/freebsd-head.git
https://code.google.com/p/freebsd-head
Pour hg :
https://bitbucket.org/freebsd/freebsd-head
svn n'est pas forcément le meilleurs gestionnaire de sources. Mais il permet de garder la rétro compatibilité avec CVS et surtout csup ainsi que d'utiliser git et hg.
Voir :
http://wiki.freebsd.org/GitWorkflow
http://www.cvsup.org/
http://www.freebsd.org/doc/en/books/handbook/cvsup.html
http://freebsd.1045724.n5.nabble.com/Why-not-give-git-a-try-was-quot-Re-head-tinderbox-failure-on-amd64-amd64-quot-td4047695.html
[^] # Re: Mes deux [euro] cents
Posté par Joris Dedieu (site web personnel) . En réponse au journal Marché unique pour les droits de licence musicale. Évalué à -1.
Ou vois-tu de bonnes choses ? La commission règle ici une question de concurrence. Cela ne changera strictement rien au fond du problème qui est que quoiqu'il en soit ce que tu achètes est un droit d'utilisation limité et pas une copie de l'oeuvre.
Ça me fait vraiment penser à quelqu'un qui astique les cuivres alors que le bateau coule ; une mesurette sans ambition de plus dans un contexte étriqué et bureaucratique. Putain on serait en droit d'attendre des choses plus ambitieuses que le règlement de petites gueguerres entre majors. La commission traite l'économie numérique comme elle a traité l'industrie et l'agriculture ; par le petit bout de la lorgnette. Gageons que le résultat sera à la hauteur.
# Mes deux [euro] cents
Posté par Joris Dedieu (site web personnel) . En réponse au journal Marché unique pour les droits de licence musicale. Évalué à -2.
Moi je dis Supaire ! Chouette ! Au point ou nous en sommes, je trouve qu'on devrait instaurer une minute quotidienne obligatoire pour applaudir aux décisions de la Commission. Et que j'entende bien les 11 millions de Grecs applaudir avec moi.
[^] # Re: serie
Posté par Joris Dedieu (site web personnel) . En réponse au journal Utiliser tmux aussi bien en local qu'en distant. Évalué à 2.
Et par rapport à des clients dédiés comme cu ou tip ? C'est intéressant ?
[^] # Re: Mauvaise facture?
Posté par Joris Dedieu (site web personnel) . En réponse au journal [Hors sujet/philosophie] Stanford Encyclopedia of Philosophy. Évalué à 2.
Je trouves que beaucoup d'articles de philo sur wikipedia fr sont tout à fait honorables. Aurais-tu des exemples de ce que tu reproches ?
[^] # Re: Just sayin...
Posté par Joris Dedieu (site web personnel) . En réponse au journal Gé(né)rer ses mots de passe. Évalué à 1.
Trop gros. Celui-là il ne passera pas :)
[^] # Re: Xtrabackup et Xtrabackup-manager
Posté par Joris Dedieu (site web personnel) . En réponse au journal La sauvegarde MySQL. Évalué à 1.
Ou pas. Je dirais que ça marche globalement bien mais il ne faut pas oublier de faire un test du jeu de backup. Je eu quelques problèmes sur les bases > à 20 GO en particulier lorsque l'innodb_file_per_table n'est pas activé. L'heure est également extrêmement importante si on stream sur le réseau.
# pas de Q
Posté par Joris Dedieu (site web personnel) . En réponse au journal La sauvegarde MySQL. Évalué à 3.
Pour l'export des structures ne pas oublier -Q pour l'abruti qui aurait nommé sa table UPDATE ou SELECT.
[^] # Re: Sécurité !
Posté par Joris Dedieu (site web personnel) . En réponse au journal Tutoriel d'autohébergement. Évalué à 3.
Chez ovh tu tapes directement les ports 10000. Pas besoin de scan :)
[^] # Re: Sécurité et pdf
Posté par Joris Dedieu (site web personnel) . En réponse au journal Tutoriel d'autohébergement. Évalué à 2.
Attention toutefois à prévoir un scenario pour se logguer si /home ne monte pas.
[^] # Re: Sécurité et pdf
Posté par Joris Dedieu (site web personnel) . En réponse au journal Tutoriel d'autohébergement. Évalué à 4.
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.
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é !
Posté par Joris Dedieu (site web personnel) . En réponse au journal Tutoriel d'autohébergement. Évalué à 2.
+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.
+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: Résilience -- 3 points 1 question
Posté par Joris Dedieu (site web personnel) . En réponse au journal Rapport sur la résilience de l'Internet en France. Évalué à 2. Dernière modification le 27 juin 2012 à 16:51.
inculte !
[^] # Re: Résilience -- 3 points 1 question
Posté par Joris Dedieu (site web personnel) . En réponse au journal Rapport sur la résilience de l'Internet en France. Évalué à 5.
Je ne suis pas sûr que le gros du downtime soit lié au protocole lui même ou a des erreurs d’architecture. Le dogme veut que les annonces soient faites par les routeurs de bordure. Du coup combien de routeurs continent d'annoncer des routes qu'ils n'ont plus (typiquement routeur à th2 serveurs à Courbevoie, lien th2 / Courbevoie tombé). Ce problème s'évite pourtant très simplement en faisant les annonces depuis Courbevoie et en les relayant à th2. Mais c'est contre le dogme.
Pareillement l'injection d'une route par défaut en dur dans le noyau permet d'éviter les pannes en cas de plantage des daemon de routage.
Enfin en général les gens essayent de tout faire passer par un ou deux énormes routeurs proprios alors qu'en divisant astucieusement leur réseau ils pourraient se contenter d'équipements plus légers, plus divers et minimiser l'impact des pannes.
Je ne suis pas expert mais je pense qu'a la base des grandes pannes, il y a toujours une erreur d'architecture ou un manque de diversité. Le protocole est secondaire.