Je viens vous voir car j’ai crée un scrypt iptables que j’aimerais activer au démarrage, j’ai utiliser l’outils gnome tweak permettant de glisser directement des scrypts ou autres au démarrage, mais le scrypt iptables ne fonctionne pas. ( L’outils en lui même fonctionne bien, j’ai d’autres programme ne nécessitant aucun droit root qui s’éxécute sans soucis )
Après vérification il s’avère que quand je suis en utilisateur lamba je n’ai pas l’accès nécessaire à l’execution du scrypt, j’ai pourtant donné les droits approprié mais il continue de me refuser l’accès .
Voici le message d’erreur : Fatal: can’t open lock file /run/xtables.lock: Permission denied
Le message est on ne peut plus claire, l’accès m’est refusé, mais je ne trouve pas comment me l’attribué ?
Je suppose que ton script fait appel à la commande iptables, ou à d’autres utilitaires réservés à root.
Il serait possible de rendre utilisables ces commandes pour un utilisateur standard en particulier, mais je te conseille plutôt de faire exécuter ton script par l’utilisateur root au démarrage.
Pour exécuter automatiquement un script iptables au démarrage, on le place dans le répertoire /etc/network/if-pre-up.d (appelle le iptables par exemple).
Ah, et aussi: teste ton script avant de le faire exécuter à chaque démarrage, surtout si la machine est un serveur distant. Un moyen de le tester est de sauvegarder la config actuelle dans un fichier, d’exécuter ton script, et de restaurer automatiquement la configuration après x secondes ou minutes, ce qui donne un truc comme iptables-save > config.backup && script-iptables && sleep 300 && iptables-restore < config.backup
(là ça laisse 5 minutes pour tester les nouvelles règles et vérifier que tout va bien).
Je viens d’essayer la 1er solution, car s’est celle qui me correspond le mieux, ( ce n’ai pas un serveur distant ) mais ça ne fonctionne pas .
A noter que j’ai fait quelques recherches annexe grâce à ce que tu m’as dit, apparemment le nom du fichier compte, rapport sûrement à des caractères interdit, le miens est parfeu.sh.
Le shabang etc compte aussi apparemment, mais il était déjà présent ( #!/bin/sh ) mais ça ne fonctionne pas
Les droits d’execution sont aussi là
Donc je sais pas trop, :\ je vais continuer les recherches en attendant une réponse
OK, c’est-à-dire rendre utilisable les commandes par un utilisateur standard ?
Il faudrait quelques renseignements supplémentaires:
sudo est-il installé et l’utilisateur est-il membre du groupe sudo ?
quelles sont les commandes que tu utilises dans le script ? Je suppose iptables, mais peut-être qu’il y en a d’autres (n’hésite pas à partager ton script si tu veux)
La façon la plus propre de faire ça selon moi serait d’autoriser ton utilisateur à exécuter ces commandes précédées de sudo mais sans avoir à taper de mot de passe, puisqu’on est dans un script. Pour ça, il faut utiliser visudo, pour la syntaxe je sais plus exactement, mais ça se trouve sans mal sur le web ou dans le man.
PS: quand tu dis que ça ne fonctionne pas, n’hésite à nous donner des précisions, comme le retour console. Je suppose que tu as eu un ‘permission denied’ mais bon, ça ne fait pas de mal de le préciser.
Un script placé dans /etc/network/if-pre-up.d/ doit répondre à plusieurs conditions :
il doit être exécutable (droit x)
il doit commencer par le “shebang” #!/bin/sh ou autre interpréteur approprié (bash si présence de “bashismes”)
son nom ne doit comporter que des lettres, chiffres, tirets et traits bas (underscore), pas de point.
Attention : les scripts présents dans /etc/network/if-pre-up.d/ sont exécutés lors de la configuration de chaque interface définie dans le fichier /etc/network/interface et les fichiers qu’il “source” (par défaut dans /etc/network/interfaces.d/), donc ils sont susceptibles d’être exécutés plusieurs fois et doivent être conçus en conséquence :
n’agir que pour une seule interface, par exemple l’interface de loopback “lo” qui est toujours configurée dans le fichier interfaces),
ou tester et enregistrer un état par exemple dans /run (volatil donc effacé à chaque démarrage)
ou bien pouvoir être exécuté plusieurs fois en produisant le même résultat, donc indépendamment du fait que des règles iptables sont déjà présentes ou pas.
Oui c’est exactement sa ! Il faut que l’utilisateur standard y ai accès étant donné que le scrypt ne soit rencontré aucun problèmes de droit lors de son exécution au démarrage.
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP # On drop les scans XMAS et NULL.
iptables -A INPUT -p tcp --tcp-flags FIN,URG,PSH FIN,URG,PSH -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
_Dropper silencieusement tous les paquets broadcastés.
iptables -A INPUT -m pkttype --pkt-type broadcast -j DROP
echo “Interdiction”
Ne pas casser les connexions établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Autorise le loopback (127.0.0.1)
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
echo “Loopback”
iptables -t filter -A OUTPUT -p tcp --dport 21 -j DROP
iptables -t filter -A OUTPUT -p tcp --dport 20 -j DROP
FTP In
imodprobe ip_conntrack_ftp
iptables -t filter -A INPUT -p tcp --dport 20 -j DROP
iptables -t filter -A INPUT -p tcp --dport 21 -j DROP
iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
echo “ftp ok”
Mail SMTP:25
iptables -t filter -A INPUT -p tcp --dport 25 -j DROP
iptables -t filter -A OUTPUT -p tcp --dport 25 -j DROP
Mail POP3:110
iptables -t filter -A INPUT -p tcp --dport 110 -j DROP
iptables -t filter -A OUTPUT -p tcp --dport 110 -j DROP
Mail IMAP:143
iptables -t filter -A INPUT -p tcp --dport 143 -j DROP
iptables -t filter -A OUTPUT -p tcp --dport 143 -j DROP
Mail POP3S:995
iptables -t filter -A INPUT -p tcp --dport 995 -j DROP
iptables -t filter -A OUTPUT -p tcp --dport 995 -j DROP
echo “mail ok” #log les paquets en entrée.
iptables -A INPUT -j LOG
log les paquets forward.
iptables -A FORWARD -j LOG
Après quelques recherches https://doc.ubuntu-fr.org/sudoers je viens de respecter la dite syntaxe mais le résultat escompté n’est pas au rendez vous .
Voici mon fichier de config :
La ligne %arawaks ALL=(ALL:ALL) ALL est bien évidemment temporaire, le temps que je fasse les manipulations nécessaire.
Pour être franc j’étais au boulot quand j’ai écrit le premier message, j’avoue ne pas m’être attarder, mais tu as raisons autant pour moi !
Bonsoir, @PascalHambourg tout d’abord merci à toi pour ton aide.
C’est justement ce même document que j’ai lû, et donc je fessais référence un peu plus haut
tu déplaces le script: là où il est, c’est root qui l’exécutera à l’initialisation de chaque interface. Sauf que comme le soulignait PascalHambourg, le nom de fichier ne doit pas comporter de point. Et ce que tu veux apparemment, c’est qu’il soit exécuté par un utilisateur standard, pas par root. (pour moi c’est “mieux rangé” de mettre les scripts iptables dans ce répertoire et qu’ils soient exécutés par root, mais tu es libre de faire comme tu le sens).
dans ton script, chaque iptables soit précédé de sudo (tu peux faire sed -i 's/iptables/sudo iptables/' <chemin vers parfeu.sh> pour aller plus vite)
dans le fichier sudoers (que tu édites avec la commande visudo) làl où il y a NOPASSWD, il ne faut pas mettre le chemin vers ton script, mais le chemin vers la commande iptables(normalement /sbin/iptables)
Avant de cloturer le post, j’aimerais savoir, pour l’utilisateur lambda j’aimerais qu’il puisse faire les MAJ, donc il faut que je lui autorise via sudoers le scrypt qui innitialise l’update et l’upgrade, mais je ne sais pas lequel sait … J’ai regardé dans /sbin et j’ai pensé qu’il s’agisait de unix_update mais apparemment non, vous ne serez pas lequel s’est par hasard ?
Les commandes qui permettent de faire les MàJ sur une Debian sont (au choix) apt, apt-get ou aptitude.
Je te laisse consulter les manuels de ces commandes (en faisant man <commande>) pour l’utilisation, en gros c’est <commande> update pour rafraîchir la liste des dépôts, et <commande> upgrade pour mettre à jour les paquets qui ont une version plus récente dans les dépôts.
@Sputnik93 Autant pour moi, ma question pouvait porter à confusion, je cherche à autoriser l’utilisateur à pouvoir faire les MAJ. Sauf que pour sa, il faut que je spécifie dans visudo qu’il à le droit de pouvoir executer apt-get update/upgrade/dist-upgrade.
Mais je ne sais pas quelle commande fait appel à l’update, afin de l’indiquer dans visudo.
J’ai était voir dans /sbin y a un scrypt nommé unix_update, mais ça ne doit pas être sa étant donné que quand je l’indique dans visudo, l’utilisateur arawaks ne peut toujours pas utiliser ces commandes.
Ben si ton utilisateur est dans le groupe sudo (tu peux vérifier avec id <nom d'utilisateur>) il peut exécuter sudo apt-get tout-ce-qu'il-veut, il devra juste taper son mot de passe.
Après, si tu le souhaites, tu peux en effet restreindre les commandes que l’utilisateur peut exécuter avec sudo, au lieu du ALL tu mets juste les chemins vers les commandes autorisées (tu peux trouver le chemin d’une commande en tapant which <nom de la commande>, pour apt-get c’est /usr/bin/apt-get).
Tu peux aussi vouloir faire en sorte qu’il puisse faire des sudo apt-get xxx sans taper de mot de passe, dans ce cas tu mets le chemin vers apt-get à la suite d’iptables, sur la ligne avec NOPASSWD.
Je sais pas trop à quoi ça sert, /sbin/unix_update, mais d’après file c’est un LSB shared object (une librairie quoi), donc c’est pas ce que tu cherches.
