Vous n'êtes pas identifié(e).
L'autre machine a systemd, mais je n'ai pas créé de service natif, j'ai utilisé la prise en charge des anciens scripts sysvinit. J'ai dû adapter l'en-tête LSB car le runlevel S ne semble plus pris en compte.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par abumbra (07-05-2019 22:46:09)
Hors ligne
Debian testing, nvidia 980 gtx sli, cm asurock 16 gb ram cpu i7 4,2 ghz
Hors ligne
Hors ligne
2) créer un /usr/lib/systemd/system/iptables.service
D'après la page de manuel de systemd.unit, les unités systemd créées localement devraient être dans placées dans /etc/systemd/system, pas dans /usr dont le contenu est censé provenir des paquets et qui peut être monté en lecture seule. D'autre part /usr/lib/systemd/system ne fait pas partie des répertoires mentionnés où systemd va chercher des unités. Pour les unités installés par les paquets, c'est plutôt /lib/systemd/system.
ExecStart=/home/nevermore/iptables start
C'est une très mauvaise idée de faire exécuter avec les privilèges root un script placé dans un répertoire où un utilisateur normal peut écrire. D'autre part si /home est un système de fichiers séparé de la racine, il n'est pas garanti qu'il sera déjà monté lors de l'exécution.
3) script dans /etc/init.d
C'est la même chose que 1).
5) variante de if-pre-up : dans /etc/network/interfaces, après wlo1 : pre-up iptables-restore < /etc/iptables_rules (règles le problème des applications multiples)
C'est quoi, wlo1 ? Je croyais que la connexion réseau était gérée par NetworkManager ? Si une interface est configurée dans /etc/network/interfaces, par défaut elle est ignorée par NetworkManager.
Il semblerait donc qu'avec if-pre-up tout soit bien appliqué avant même la configuration de l'interface !
Seulement quand l'interface est configurée dans /etc/network/interfaces ! Aucune garantie quand l'interface est configurée par NetworkManager.
Certes, NetworkManager inclut un script /etc/NetworkManager/dispatcher.d/01ifupdown qui exécute les scripts d'ifupdown lorsque NetworkManager agit sur une interface, mais si on regarde dans le code on voit que l'exécution des scripts pre-up est désactivée.
Aussi, on m'a fait remarquer "et ton nat et mangle ?". On est bien d'accord que sur une machine non routeur, je laisse tout à accepte
Rien à voir avec le fait qu'une machine soit routeur ou non. Les tables mangle et nat ne sont pas faites pour le filtrage donc il n'y a aucune raison de mettre leurs politiques par défaut à DROP. Les chaînes des différentes tables sont en cascade, et quel que soit son chemin tout paquet passe forcément par une (et une seule) chaîne de la table filter qui permet de faire le filtrage.
Ceci dit, la dernière version de ton script ne laisse pas les politiques à ACCEPT, elle les laisse dans l'état où elles sont sans y toucher. Suffisant quand le script est exécuté au démarrage avant qu'iptables ait été utilisé, mais pas forcément pour remettre à l'état voulu après un bidouillage en cours de session.
e n'y ai étrangement rien trouvé pour appliquer les règles au boot. Ou je suis passé devant sans le voir, ou rien à ce sujet.
La dernière fois que j'ai parcouru ce tutoriel (il y a longtemps certes, je ne sais pas s'il évolue encore), il ne parlait pas des moyens de mettre en place un jeu de règles. C'est trop dépendant du système et de la distribution.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
3) ne pas l'exécuter en root ?!
Je n'ai pas écrit cela. J'ai écrit que c'est un risque de sécurité d'exécuter en tant que root un programme qui peut être modifié par un utilisateur normal. Or /home/nevermore/ est modifiable par l'utilisateur nevermore. Si cet utilisateur est compromis, il peut remplacer le programme par un programme malveillant.
Les règles iptables ne peuvent être manipulées qu'avec la "capacité" CAP_NET_ADMIN. Je ne sais pas si on peut lancer un service avec seulement les capacités nécessaires, sinon il faut le lancer en root.
Dernière modification par raleur (08-05-2019 17:11:39)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par raleur (08-05-2019 17:29:51)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par abumbra (08-05-2019 17:33:56)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par abumbra (08-05-2019 19:14:13)
Hors ligne
jusque là j'utilisais 750 pour rendre exécutables mes scripts. Tu m'as parlé de 755 ?
Le fait qu'il soit ou non lisible et exécutable par tout le monde ne fait pas une grosse différence si le script ne contient rien de sensible.
même en ipv4, même si tout fonctionne, bloquer icmp n'est optimal, et surtout "pas génial" pour les autres ? Un intérêt à faire comme en icmpv6 et n'autoriser que certains types, quitte à imposer des limites ?
Bien sûr. Il est préférable d'accepter les mêmes types d'erreur qu'ICMPv6 dans l'état RELATED, sauf packet-too-big qui n'existe pas en ICMPv4.
Il vaut mieux montrer que raconter.
Hors ligne
Bien sûr. Il est préférable d'accepter les mêmes types d'erreur qu'ICMPv6 dans l'état RELATED, sauf packet-too-big qui n'existe pas en ICMPv4.
C'est aussi simple que ça, simple copier coller, juste remplacer icmpv6 par icmp tout court, et supprimer packet-too-big ? Rien besoin de plus ?
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne