Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 12-05-2018 20:39:39

Henry33
Membre
Inscription : 23-12-2016

sudo iptables-save > /etc/[fichier] : Permission denied

Bonjour à vous,

En faisant

sudo iptables-save > /etc/iptables.ipv4.nat



j'obtiens

-bash: /etc/iptables.ipv4.nat : Permission denied



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/

-rw-r--r-- 1 root root    1050 May 12 17:30 iptables.ipv4.nat



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 20:57:08)

Hors ligne

#2 12-05-2018 21:30:42

èfpé
Membre
Inscription : 10-07-2016

Re : sudo iptables-save > /etc/[fichier] : Permission denied

Bonsoir,

Alors sauf erreur de ma part sudo et redirections ne font pas bon ménage, le plus simple est de passer root avec :

sudo -s


ensuite tu pourras tranquillement exécuter la commande 'iptables-save > /etc/iptables.ipv4.nat' et quitter avec exit.


« He's the original. There are no carbon copies of that one. »
— Babe Bennett

Hors ligne

#3 12-05-2018 21:48:32

Henry33
Membre
Inscription : 23-12-2016

Re : sudo iptables-save > /etc/[fichier] : Permission denied

Salut,

C'est ce que je me suis dit, vu que le fichier appartient à root, mais j'ai déjà réalisé cette commande avec sudo (en suivant une astuce pour forcer la suppression une règle d'iptables)... Je sais pas ce que j'ai fait entre temps, mais ça marche plus...

Hors ligne

#4 13-05-2018 11:29:18

raleur
Membre
Inscription : 03-10-2014

Re : sudo iptables-save > /etc/[fichier] : Permission denied

Piège bien connu. La redirection n'est pas gérée par sudo mais par le shell appelant, qui n'a pas les droits root.
Pourquoi s'enquiquiner avec sudo sur un routeur où la majorité des commandes est exécutée en tant que root ?

Hors ligne

#5 13-05-2018 11:44:49

Henry33
Membre
Inscription : 23-12-2016

Re : sudo iptables-save > /etc/[fichier] : Permission denied

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 ?

Hors ligne

#6 13-05-2018 11:57:44

valdo
Membre
Lieu : Paris
Distrib. : Debian 9
Noyau : 3.16.0-4-amd64
(G)UI : DE: MATE 1.16.1 WM: Metacity (Marco)
Inscription : 04-10-2016

Re : sudo iptables-save > /etc/[fichier] : Permission denied

sudo bash -c "ma_commande >> mon_fichier"

Si jamais tu veux malgré tout utiliser ton sudo smile

519664.gifOupsoups  ~# Where there is a shell, there is a way.

Hors ligne

#7 13-05-2018 11:59:35

raleur
Membre
Inscription : 03-10-2014

Re : sudo iptables-save > /etc/[fichier] : Permission denied

A mon avis, oui. Désactiver le mot de passe root est une bêtise car il peut être bien utile dans certaines situations, où il est impossible ou inadapté de se connecter avec un utilisateur normal. Evidemment le mot de passe root doit être solide.
Quant à rester en root en permanence, normalement sur un serveur ou routeur on ne reste pas connecté en permance mais seulement le temps de faire ce qu'on a à faire, et généralement cela nécessite les droits root. Le seule intérêt de sudo, ce serait s'il y avait plusieurs co-administrateurs et qu'on voulait savoir qui fait quoi.

Hors ligne

#8 13-05-2018 12:00:00

Henry33
Membre
Inscription : 23-12-2016

Re : sudo iptables-save > /etc/[fichier] : Permission denied

Ba, je veux, je veux... Je veux surtout faire les choses bien. Quitte à apprendre quelque chose, autant le faire correctement.


EDIT : ok, je me re-pencherai sur les mots de passe sur le Raspberry. J'avais mis ça de coté car il faut modifier le paramètre du nombres et des caractères possibles et c'est un règlage pas si simple que ça. J'ai lu quelques pages là-dessus et certains ont eu des difficultés (dont moi) à activer les paramètres les caractères spéciaux. Du coup, je me suis intéressé au d'autres choses plus "urgentes".

Dernière modification par Henry33 (13-05-2018 12:06:13)

Hors ligne

#9 13-05-2018 18:25:55

mazkagaz
Membre
Distrib. : Debian stretch essentiellement
Noyau : Ben ça dépend des machines.
(G)UI : La plupart du temps gnome, souvent aucun.
Inscription : 13-05-2018

Re : sudo iptables-save > /etc/[fichier] : Permission denied

Henry33 a écrit :

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

#10 13-05-2018 18:37:24

Henry33
Membre
Inscription : 23-12-2016

Re : sudo iptables-save > /etc/[fichier] : Permission denied

Ca demande un mot de passe que je ne peux pas donner. Vu qu'il n'y a pas de mot de passe, y a rien à valider donc confirmer le champ vide donne mot de passe invalide. C'est ce qui se passe à partir de la console "utilisateur", je n'ai aucune idée de ce que ça donne derrière (par SSH et autres).

Hors ligne

#11 13-05-2018 18:57:01

mazkagaz
Membre
Distrib. : Debian stretch essentiellement
Noyau : Ben ça dépend des machines.
(G)UI : La plupart du temps gnome, souvent aucun.
Inscription : 13-05-2018

Re : sudo iptables-save > /etc/[fichier] : Permission denied

L'utilisateur qui lance la commande "sudo su", il n'a pas de mot de passe ?

Je pose cette question parce que j'ai un pote qui m'a aussi dit qu'il utilisait sudo pour la sécurité et avec sa configuration de sudo, en tapant "sudo su", il suffisait d'entrer le mot de passe de l'utilisateur qui a les droits sudo et hop, il se retrouvait en root. Donc finalement, devenir root supposait de trouver son mot de passe, ce qui revient au même que trouver celui de root (en terme de protection).

Sur la plupart des raspberry pi sous raspbian, c'est encore pire : tu tapes "sudo su" avec l'utilisateur "pi" et tu te retrouves en root sans même avoir eu à taper ton propre mot de passe... Sachant que la plupart des utilisateur de raspbian ne changent même pas le mot de passe par défaut de pi... Niveau sécurité, on est vraiment au ras des pâquerettes dans ce cas précis.

Du coup, je suis perplexe pour ce qui est de la sécurité apportée par sudo dans ces cas là. Après, il y a possibilité de bien paramétrer sudo pour ne pas rendre tout ça possible et effectivement ajouter une couche de sécurité en confiant quelques accès bien choisi à certains utilisateurs auxquels on veut confier certains droits superutilisateur mais pas tous les droits. Mais si on est seul maître à bord sur sa propre machine, je n'en vois pas l'intérêt (mais je ne sais pas tout donc il y en a peut-être un).

Bref, je ne vais pas m'étendre davantage parce que je ne suis pas certain de résoudre ton problème et je n'ai pas envie de troller ton post. Je me disais juste que si tu acceptais l'idée d'utiliser le compte root et si dans ton cas ça ne posait pas de soucis majeur de sécurité, tu pourrais régler ton soucis.

Autre remarque : je ne sais pas pourquoi tu fais cette sauvegarde des règles iptables (pour les réappliquer au reboot par exemple ? ). Si tel est le cas, tu peux aussi te faciliter la vie avec le paquet iptables-persistent : idéal pour une machine avec un accès physique, un peu dangereux sans accès physique (ou IPMI). Et lorsque tu changes une règle, pour la garder, tu lances un "dpkg-reconfigure iptables-persistent" et tu re sauves les nouvelles règles. Mais bon je dis tout ça mais comme je ne sais pas ce que tu veux faire de ton fichier dat, ça ne te sert peut-être à rien.

Hors ligne

#12 13-05-2018 19:18:58

raleur
Membre
Inscription : 03-10-2014

Re : sudo iptables-save > /etc/[fichier] : Permission denied

Je ne suis pas sûr que iptables-persistent se combine bien avec fail2ban.
D'un autre côté, je ne vois pas trop l'intérêt de fail2ban sur ce routeur.

Dernière modification par raleur (13-05-2018 19:27:40)

Hors ligne

#13 13-05-2018 19:21:31

Henry33
Membre
Inscription : 23-12-2016

Re : sudo iptables-save > /etc/[fichier] : Permission denied

Voila le résultat pour su root à partir de la console utilisateur pi quand le mot de passe root à été supprimé :

pi@raspberrypi:~ $ su root
Password:
su: Authentication failure
pi@raspberrypi:~ $
 



Voici le résultat avec sudo su:

pi@raspberrypi:~ $ sudo su
root@raspberrypi:/home/pi#
 



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

#14 13-05-2018 19:24:30

mazkagaz
Membre
Distrib. : Debian stretch essentiellement
Noyau : Ben ça dépend des machines.
(G)UI : La plupart du temps gnome, souvent aucun.
Inscription : 13-05-2018

Re : sudo iptables-save > /etc/[fichier] : Permission denied

raleur a écrit :

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

#15 13-05-2018 19:27:50

Henry33
Membre
Inscription : 23-12-2016

Re : sudo iptables-save > /etc/[fichier] : Permission denied

raleur a écrit :

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

#16 13-05-2018 19:36:52

mazkagaz
Membre
Distrib. : Debian stretch essentiellement
Noyau : Ben ça dépend des machines.
(G)UI : La plupart du temps gnome, souvent aucun.
Inscription : 13-05-2018

Re : sudo iptables-save > /etc/[fichier] : Permission denied

Henry33 a écrit :

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

#17 13-05-2018 19:47:08

raleur
Membre
Inscription : 03-10-2014

Re : sudo iptables-save > /etc/[fichier] : Permission denied

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.

Hors ligne

#18 13-05-2018 21:20:28

mazkagaz
Membre
Distrib. : Debian stretch essentiellement
Noyau : Ben ça dépend des machines.
(G)UI : La plupart du temps gnome, souvent aucun.
Inscription : 13-05-2018

Re : sudo iptables-save > /etc/[fichier] : Permission denied

raleur a écrit :

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 wink )

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. smile

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 wink 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 09:26:06)

Hors ligne

#19 14-05-2018 09:17:49

mazkagaz
Membre
Distrib. : Debian stretch essentiellement
Noyau : Ben ça dépend des machines.
(G)UI : La plupart du temps gnome, souvent aucun.
Inscription : 13-05-2018

Re : sudo iptables-save > /etc/[fichier] : Permission denied

Alors je confirme que ni iptables-persistent, ni fail2ban (ni docker d'ailleurs) ne gère ça sur stretch.

Sur l'un de mes serveurs par exemple, "iptables -L" me renvoie 4 règles identiques pour la chaîne f2b-sshd et 3 pour les chaînes relatives à docker. Donc maintenant c'est certain, et merci à raleur pour m'avoir fait identifier ce point, ni l'un ni l'autre ne traite ce cas de figure. Et mon observation à la va vite "mes règles ne semblent pas grossir" était fausse... On voit souvent ce qu'on a envie de voir...

Quelles en sont les conséquences ? Il me semble qu'un paquet reçu sera traité par la première règle rencontrée qui correspond au paquet. Du coup, il me semble que les règles redondantes, étant donnée qu'elle sont toutes les une à la suite des autres, sont simplement inutiles mais n'apportent pas de faille de sécurité. Ai-je raison de penser que cela n'est pas grave et que ça n'a aucun impact sur la sécurité, même si ça n'est pas très propre ? Là je veux bien qu'un pro d'iptables me renseigne et me dise si c'est grave (au delà du fait que c'est moche...).

Sinon, pour penser évolution et traitement du problème, je me dis qu'il faudrait par exemple normaliser l'utilisation des chaînes iptables en spécifiant par exemple que toutes les chaînes crées par des scripts qui redémarrent automatiquement aient le même préfixe et que ce préfixe leur soit réservé (par exemple "AUTO-") afin que des outils comme iptables-persistent puissent les identifier et les filtrer. Mais ce genre de spécification fait partie du domaine des dieux, d'ailleurs ceux-ci y ont probablement déjà pensé (à ça ou à des solutions bien plus malines) et ce genre de décision peut avoir de nombreux impacts et ne se prend pas à la légère. Bref, je digresse... Mais j'ai appris quelque chose, donc je suis content smile

WORKAROND : arrêter tous les demons type fail2ban et docker le temps du dpkg-reconfigure de iptables-persistent et les redémarrer ensuite.

Dernière modification par mazkagaz (14-05-2018 09:33:17)

Hors ligne

#20 14-05-2018 12:22:30

lebardix
Adhérent(e)
Lieu : Plan de Cuques
Distrib. : Version 9.2 (Stretch) 64 bits
Noyau : Linux 4.9.0-3-amd64
(G)UI : MATE Desktop Environment 1.16.2
Inscription : 15-10-2013

Re : sudo iptables-save > /etc/[fichier] : Permission denied

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 ?

En ligne

#21 15-05-2018 07:51:40

valdo
Membre
Lieu : Paris
Distrib. : Debian 9
Noyau : 3.16.0-4-amd64
(G)UI : DE: MATE 1.16.1 WM: Metacity (Marco)
Inscription : 04-10-2016

Re : sudo iptables-save > /etc/[fichier] : Permission denied

lebardix a écrit :

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.


519664.gifOupsoups  ~# Where there is a shell, there is a way.

Hors ligne

#22 15-05-2018 11:00:57

raleur
Membre
Inscription : 03-10-2014

Re : sudo iptables-save > /etc/[fichier] : Permission denied

mazkagaz a écrit :

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.

valdo a écrit :

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.

Hors ligne

Pied de page des forums