Vous n'êtes pas identifié(e).
j'obtiens
Cette erreur "vient d'apparaitre", j'ai déjà utilisé la commande iptables-save > /etc/[fichier] et ça marchait. J'ai dû faire quelque chose entre temps et maintenant ça ne marche plus... Mes seules manipulations ont été, à un moment, de désinstaller puis de réinstaller fail2ban ou d'éditer ce fichier directement.
Je peux éditer le fichier avec sudo nano et enregistrer les modifs, mais pas par la commande iptables-save...
Résultat de ls -l dans /etc/
J'ai essayé de créer un autre fichier de sauvegarde pour les règles d'iptables, même réponse...
Comment je peux débloquer ça ?
Merci pour votre aide.
Dernière modification par Henry33 (12-05-2018 19:57:08)
Hors ligne
ensuite tu pourras tranquillement exécuter la commande 'iptables-save > /etc/iptables.ipv4.nat' et quitter avec exit.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
~# Where there is a shell, there is a way.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par Henry33 (13-05-2018 11:06:13)
Hors ligne
Salut,
Par deux raisons toutes simples: j'ai lu qu'il valait mieux ne pas rester en root en permanence (même si je comprends l’intérêt sur un serveur, c'est même plutôt logique) et que pour des raisons de sécurité, il valait même mieux supprimer le mot de passe root pour empêcher de se logger dessus. C'est pour ça que j'utilise sudo.
C'est un mauvais conseil ?
Juste pour évaluer le gain de sécurité à ne pas avoir un mot de passe pour root, que se passe-t-il si tu tapes "sudo su" ?
Hors ligne
Hors ligne
Hors ligne
Dernière modification par raleur (13-05-2018 18:27:40)
Il vaut mieux montrer que raconter.
Hors ligne
Voici le résultat avec sudo su:
On dirait bien qu'il est possible de contourner le mot de passe root avec sudo su depuis un utilisateur... C'est rigolo.
Mais il faut savoir une chose : un Raspberry Pi n'est pas fait pour être sécurisé ! C'est un module d'apprentissage (comprendre=pour les enfants) donc il est normal qu'il n'y ait pas les mêmes règles/réglages de sécurité que sur une distribution normale. C'est un OS Debian, c'est sûr, mais qui a été simplfié.
Hors ligne
Je ne suis pas sûr que iptables-persistent se combine bien avec fail2ban.
D'un aute côté, je ne vois pas trop l'intérêt de fail2ban sur ce routeur.
Je n'ai pas eu à déplorer de problème avec fail2ban (que j'utilise) et iptables-persistent. Ni d'ailleurs avec d'autre chaînes créées par exemple par des dockers. Mais j'ai peut-être eu de la chance.
Tu as des sources relatant de tels soucis ? Ça m'intéresserait parce que je n'aimerais pas être impacté...
Hors ligne
Je ne suis pas sûr que iptables-persistent se combine bien avec fail2ban.
D'un aute côté, je ne vois pas trop l'intérêt de fail2ban sur ce routeur.
Dans mon cas, c'est sûr, l’intérêt est limité puisque le risque est limité, mais autant le configurer (et apprendre) tant que j'y suis. Ce n'est que quelques lignes/heures en plus mais une fois que ce sera configuré, ça sera toujours ça de plus. Et puis je ne suis pas à l'abri d'un type/nana qui voudrait essayer quelque chose (intrusion/apprentissage/essai/n'importe quoi). J'ai du temps à y consacrer en ce moment, alors j'en profite.
Hors ligne
On dirait bien qu'il est possible de contourner le mot de passe root avec sudo su depuis un utilisateur... C'est rigolo.
Mais il faut savoir une chose : un Raspberry Pi n'est pas fait pour être sécurisé ! C'est un module d'apprentissage (comprendre=pour les enfants) donc il est normal qu'il n'y ait pas les mêmes règles/réglages de sécurité que sur une distribution normale. C'est un OS Debian, c'est sûr, mais qui a été simplfié.
Un raspberry pi est un ordinateur, chacun en fait ce que bon lui semble (firewall+nat, système domotique, routeur , serveur mail, partage nfs, multimedia pc, pilotage embarqué sur un drone, gestion d'une imprimante 3D, ...etc...). La sécurité nécessaire dépendra de l'utilisation que tu veux en faire. Tant que le jouet n'est ni connecté à un réseau sensible (le tien), ni accessible d'une manière ou d'une autre (physique, par le réseau via un exploit d'un cms installé dessus par exemple), ça n'est effectivement pas très grave.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Pas besoin de source, juste de la logique.
Fail2ban crée des règles iptables à la volée et iptables-persistent les sauvegarde et les restaure au redémarrage. Mais est-ce que fail2ban les efface au démarrage ? Sinon elles s'accumulent.
La logique se base sur des postulats. (Là c'est le prof de maths qui te parle )
Ton postulat semble être : "iptables-persistent" copie toutes les règles même celles de fail2ban. Tu en déduis donc qu'au redémarrage celles-ci s'accumulent avec celles de la nouvelle instance de fail2ban.
Ensuite tu émets l'hypothèse : peut-être que fail2ban les efface au démarrage pour y mettre les nouvelles. Ce doute par rapport à la proposition précédente me semble tout à fait louable.
Du coup, tu en conviendras, une source vers un article écrit par quelqu'un de mieux informé que nous deux lèverait le doute. La logique ne viendra pas à bout du problème sans éléments supplémentaires. La logique pourrait en venir à bout à condition de mener une investigation et d'apporter des éléments de preuve. De mon côté, le seul élément que j'ai à apporter est l'observation : j'utilise fail2ban et iptables-persistent sur la même machine et les règles iptables ne semblent pas grossir à chaque redémarrage. Mais est-ce que c'est bien géré ou est-ce un coup de chance ? Ai-je introduit une instabilité, une faille sur mon système ? Je ne sais pas. Ça a l'air de bien se passer mais j'aimerai en être certain. (FAUX : voir message suivant.) Du coup je chercherai la source et si je la trouve, je partagerai Et en attendant, je vais un peu plus attentif à ce qui se passe au niveau de mes règles iptables (je testerai par exemple un redémarrage après avoir désactivé le démarrage automatique de fail2ban et je verrai bien si mes règles iptables contiennent des restes de chaînes fail2ban après le reboot).
Ça me rappelle un vieux post que j'avais écrit il y a longtemps pour tenter de récupérer des données sur un disque dur foireux : un gars m'avait répondu sûr de lui que je pouvais le jeter et qu'il n'y avait rien à faire. Je lui avais demandé pourquoi et il m'avait envoyé balader parce que ça semblait évident. Sauf qu'en fait j'ai récupéré mes données... Et j'ai partagé ma résolution du problème en faisant remarquer au gars qui m'avait apporté son assistance (et je l'en remercie, parce que même s'il s'était trompé, je sais que ce n'était pas son intention), que j'avais quand même bien fait de ne pas croire ses conclusions sans preuves.
Donc je te remercie (vraiment hein, je me méfie des message, le ton est souvent mal interprété) de me donner du grain à moudre mais je ne peux pas me contenter d'en rester là. Il va falloir que j'en ai le cœur net.
Dernière modification par mazkagaz (14-05-2018 08:26:06)
Hors ligne
Dernière modification par mazkagaz (14-05-2018 08:33:17)
Hors ligne
Hors ligne
euh, un compte root sans mot de passe... sans doute une situation délicate en cas de probleme de filesystem au démarrage :
Comment entrer en mode single ?
Tu peux entrer en sigle user ou emergency mode, ou exploiter la faille du grub, ou un system-rescue, etc.
~# Where there is a shell, there is a way.
Hors ligne
Alors je confirme que ni iptables-persistent, ni fail2ban (ni docker d'ailleurs) ne gère ça sur stretch.
Il m'arrive d'avoir des intuitions qui se révèlent justes.
Tu peux entrer en sigle user ou emergency mode, ou exploiter la faille du grub, ou un system-rescue, etc.
Il faut le mot de passe root pour lancer un shell en single user ou emergency mode.
Quant aux deux autres méthodes, elles sont beaucoup moins pratiques.
Il vaut mieux montrer que raconter.
Hors ligne