Je me permet un petit up pour ma dernière question.
Et même si ça sera redondant avec mon autre post, je me permet de les poser ici aussi :
Quelle est la meilleure solution pour appliquer mes règles avant la connexion au réseau via le networkmanager ? On m'a fait remarquer que /etc/network/if-pre-up.d/iptables n'allait pas, et init.d/ non plus… Je suis coincé.
Tout ce que je vois comme littérature sur le sujet ne mentionne que ces possibilités là (ou iptables-persistent qui n'est visiblement plus d'actualité).
Aussi, d'autres optimisations quant aux règles ?
A part un pare-feu bien configuré, d'autres outils nécessaires pour assouvir ma fichue paranoïa ? ahah.
Du coup, j'ai fais un iptables-save une fois mon script appliqué, puis automatisé le restore au démarrage. Tout semble fonctionner.
Pour les logs, dans la mesure ou Psad ne me donne plus d'alerte en input depuis qu'iptables est bien configuré, j'ai supprimé INPUT -j LOG.
Les questions qui me reste sont :
1) est-il possible d'encore rendre plus sécurisé iptables, ou je suis arrivé au bout des conseils et de mes lectures, et on ne peut guère faire mieux ?
2) comment appliquer les règles avant la connexion à internet via le network manager ? si la solution /etc/network/if-pre-up.d/iptables n'est pas adéquate, quelle est à la bonne.
Tout ce que je vois comme tutos, docs etc. c'est ou dans /etc/network/if-pre-up.d/iptables ou dans init.d.
Question bête, oui je comprend bien le pourquoi. Seul souci j'utilise PSAD, qui nécessite le log des INPUT. J'impose une limite à LOG ? Je me passe de PSAD ?
Je suis perdu. Mes règles sont pourtant bien appliquées ! Mais il y a une période de latence, si je comprend bien, où la machine est connectée au réseau sans que les règles soient appliquées ?
Je ne comprend juste pas. Configuré comme il est, mon script s'applique avant la connexion en network, non ?
Et je vois deux manière d'utiliser save et restore :
Entrer ses règles, faire un iptables-save > /etc/iptables.rules.
Puis iptables-restore < /etc/iptables_rules en haut du script, à placer soit dans /etc/network/if-pre-up.d/iptables, soit directement dans /etc/network.
Selon la doc officielle debian.
Ou faire un script avec les * et commit comme indiqué dans ton lien, mais comment faire pour qu'il soit appliqué au bon moment au démarrage ?
Posté par redraven .
En réponse au message IPtables -configuration.
Évalué à 1.
Dernière modification le 26 avril 2019 à 07:46.
Ok, ça, ça me permet d'y voir plus clair quand l'utilité de ma démarche.
Ceci dit, comme je disais, l'utilité n'est pas ce qui m'intéresse, j'ai envie de répondre à ma curiosité, et à ma paranoïa dans une moindre mesure (plus exactement, sensation de sécurité).
Si configurer IPtables me permet de répondre à ces deux exigences, quand bien même ça ne serait pas utile d'un strict point de vue sécurité vu les conditions dans lesquelles j'utilise ce PC…
Mais je comprend parfaitement ce que tu me dis. Et ça m'aide grandement, parce que je me prennai bien la tête à vouloir tout régler au plus vite.
Vu qu'il n'y a pas de vraie utilité, et donc aucune urgence, au moins maintenant je me prendre mon temps.
// Mail SMTP
// iptables -A INPUT -p tcp --dport 25 -j DROP
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
// iptables -A INPUT -p tcp --dport 587 -j DROP
// iptables -A OUTPUT -p tcp --dport 587 -j DROP
// Transmission
iptables -A INPUT -p udp --dport 51413 -j ACCEPT
iptables -A OUTPUT -p udp --dport 51413 -j ACCEPT
// NTP (horloge du serveur)
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
Qui me semble fonctionnel et minimal.
Sauf que le même ensemble de règles avec ip6tables en plus, tout fonctionne sauf smtp.
Merci d'avance.
NB : comment faire sur ce forum pour que # ne soit pas interpreté comme titre, afin de gagner en lisibilité ? Remplacé par // bien que ça ne fasse aucun sens, en attendant.
Encore une petite question, tu me disais que iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT ne faisait pas de sens (established sur output).
Mais sans, qu'avec le input established, ça ne marche plus ! Plus d'accès au net.
Et petite question, maîtrises-tu par extension ip6tables ?
J'avais lu qu'il suffisait de transposer ses règles iptables. Mais juste avec iptables, smtp fonctionne, avec iptables + ip6tables, il ne fonctionne plus. Or je l'utilise pour m'envoyer des rapports type logwatch etc.
Et donc, si je comprend bien, la règle established, elle, ne permettrai pas à un petit malin de faire la même chose ? Après tout, le port est finalement ouvert de même ?
A vrai dire, votre "conflit" m'est utile, sans ça ce thread n'avancerai pas autant, et je n'aurai pas appris autant de chose en aussi peu de temps ahah !
Merci encore, vraiment.
Donc si je comprend bien, la règle input established ne laisse passer que le retour des ports que j'ai autorisé, donc tout reste sécurisé ?
Du coup, la règle established que j'avais précisé dans le script initial pour transmission est des plus superflu!.
Je vais retravailler tout ça et vous pondrai une version finale ce soir.
Ce qui m'intrigue c'est que sur un autre forum, ainsi qu'un ami, m'ont dit "que tes règles ne servent à rien, sans ta ligne acceptant les established, rien ne passe". Commentaire à prendre en compte et possibilité de faire fonctionner le tout sans cette ligne, via une autre solution ? Ou on m'a juste embrouillé et commentaires à oublier ?
Posté par redraven .
En réponse au message IPtables -configuration.
Évalué à 1.
Dernière modification le 25 avril 2019 à 13:34.
Je reviens à la charge, même si ça ne va pas plaire à tout le monde.
De là où j'en suis dans ma compréhension de tcp/ip et d'iptables, après avoir tout configuré en drop (mais si inutile pour output et forward, mais bref), un code minimal devrait suffire :
iptables -A INPUT -i lo -j ACCEPT
DNS
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
HTTP
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
HTTPS
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
Sauf que non. Ce que je ne comprend pas, c'est pourquoi sans les lignes :
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
rien ne fonctionne. Autoriser lo, dns, http et https devrait pourtant pouvoir suffire à accéder au net, de ce que je comprend. Non ?
Mes excuses, après ça je vous laisserai en paix jusqu'à lecture complète de ce que je suis sensé lire.
Je lis pas mal sur le sujet, mais j'avance à petit pas, et il me faut un but concret pour me motiver, d'où l'idée d'iptables sur une machine de bureau, avant un éventuel serveur une fois les bases des notions de réseaux acquises et la config de iptables, fail2ban et ce genre de chose maîtrisée. Juste source de motivation, et curiosité. Aussi, il y a quelque chose de rassurant à un pare-feu bien configuré pour un PC souvent utilisé en déplacement.
Ceci dit, je reviendrai sans doute poster un autre iptables avant d'avoir pleinement maîtrisé la doc de TCP/IP. Ne m'en veux pas, s'il te plait. Ahah.
Aussi, et parce que la qualité des sources comptent, auriez vous quelques liens et tutos à partager, peut-être mieux conçu que ce que j'ai ? (je suis entre openclassrooms et un cours d'un ami en info).
Posté par redraven .
En réponse au message IPtables -configuration.
Évalué à 1.
Dernière modification le 24 avril 2019 à 15:15.
Merci tout le monde !
Sincèrement, toutes ces infos me sont précieuses.
Il n'y a aucun intérêt, dans mon cas, à avoir un pare-feu, à part l'occasionnelle connexion à un réseau public ce genre de chose.
C'est de la pure curiosité. J'ai lu un article, puis j'ai voulu comprendre comme ça fonctionnait. Aussi, je n'exclu pas du tout d'avoir un serveur un jour, juste par… curiosité et pour quelques projets, donc pas nécessairement inutile non plus comme compétence.
Les torrents fonctionnent ! Mais on m'avait fait remarqué que sans mes deux lignes established, mes règles ne servaient à rien, et vrai que sans elles rien ne marche. Du coup, bien perdu ! Est-ce correct, ou ça ne l'est pas ?
J'avais bien vu related, et vu que je me suis amusé à tout essayé règle par règle, sans, tout marche. Donc j'ai laissé sans.
Donc à revoir :
1) La façon de loguer
2) plein de drop spécifiés inutiles vu que policy drop par défaut
3) quant au doublon established pour transmission… je ne ferai pas justement mieux de précsier established ligne par ligne, port par port, plutôt que toutes les autorisées.
Et.. je me tentais à faire de même avec ip6tables, vu qu'apparement je suis en ipv6… Sauf que je partait du principe qu'à règles identiques, tout marcherai de même. Sauf que nom, c'est l'envoi de mail via smtp qui ne fonctionne plus.
Merci bien cimcim ! C'est ce que j'avais cru comprendre. Du coup, mon utilisation d'established reste sécurisée ? c'est mettre un new à cet endroit qui serait une jolie bêtise.
Bernez : aucun problème, comme je disais, je débute.
Je m’intéresse à iptables en parallèle de la lecture de plusieurs tutos/articles sur les réseaux, les protocoles etc.
Les premiers paragraphes sont du copier coller, oui. Et après lecture, je comprend parfaitement la partie sur les invalid, qui semble logique, un peu moins la partie avec les --tcp-flags (c'est ma lecture du moment, tout lire sur ce qui suis ce paramètre).
Pour la suite, par contre, j'ai passé des heures et des heures à tester chaque règle jusqu'à ce que firefox, transmission etc. fonctionne, avec le nombre de ligne minimal. Il me semblait avoir tout compris à ces paragraphes là, pourtant. J'ai fait du netstat et tcpdump pour savoir quel process, quel port etc.
# Petit up
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1.
Je me permet un petit up pour ma dernière question.
Et même si ça sera redondant avec mon autre post, je me permet de les poser ici aussi :
Quelle est la meilleure solution pour appliquer mes règles avant la connexion au réseau via le networkmanager ? On m'a fait remarquer que /etc/network/if-pre-up.d/iptables n'allait pas, et init.d/ non plus… Je suis coincé.
Tout ce que je vois comme littérature sur le sujet ne mentionne que ces possibilités là (ou iptables-persistent qui n'est visiblement plus d'actualité).
Aussi, d'autres optimisations quant aux règles ?
A part un pare-feu bien configuré, d'autres outils nécessaires pour assouvir ma fichue paranoïa ? ahah.
Merci d'avance !
# Petit up et petite question
Posté par redraven . En réponse au message Iptables - Ip6tables - avis. Évalué à 1.
Merci encore pour vos réponses.
Du coup, j'ai fais un iptables-save une fois mon script appliqué, puis automatisé le restore au démarrage. Tout semble fonctionner.
Pour les logs, dans la mesure ou Psad ne me donne plus d'alerte en input depuis qu'iptables est bien configuré, j'ai supprimé INPUT -j LOG.
Les questions qui me reste sont :
1) est-il possible d'encore rendre plus sécurisé iptables, ou je suis arrivé au bout des conseils et de mes lectures, et on ne peut guère faire mieux ?
2) comment appliquer les règles avant la connexion à internet via le network manager ? si la solution /etc/network/if-pre-up.d/iptables n'est pas adéquate, quelle est à la bonne.
Tout ce que je vois comme tutos, docs etc. c'est ou dans /etc/network/if-pre-up.d/iptables ou dans init.d.
Merci d'avance !
[^] # Re: Mon opinion
Posté par redraven . En réponse au message Iptables - Ip6tables - avis. Évalué à 1.
Question bête, oui je comprend bien le pourquoi. Seul souci j'utilise PSAD, qui nécessite le log des INPUT. J'impose une limite à LOG ? Je me passe de PSAD ?
[^] # Re: Mon opinion
Posté par redraven . En réponse au message Iptables - Ip6tables - avis. Évalué à 1.
Et en quoi mes règles de log peuvent mettre ma machine à genoux ?!
[^] # Re: Bash
Posté par redraven . En réponse au message Iptables - Ip6tables - avis. Évalué à 1.
Je suis perdu. Mes règles sont pourtant bien appliquées ! Mais il y a une période de latence, si je comprend bien, où la machine est connectée au réseau sans que les règles soient appliquées ?
Je ne comprend juste pas. Configuré comme il est, mon script s'applique avant la connexion en network, non ?
Et je vois deux manière d'utiliser save et restore :
Entrer ses règles, faire un iptables-save > /etc/iptables.rules.
Puis iptables-restore < /etc/iptables_rules en haut du script, à placer soit dans /etc/network/if-pre-up.d/iptables, soit directement dans /etc/network.
Selon la doc officielle debian.
Ou faire un script avec les * et commit comme indiqué dans ton lien, mais comment faire pour qu'il soit appliqué au bon moment au démarrage ?
Je suis perdu.
[^] # Re: Mon opinion
Posté par redraven . En réponse au message Iptables - Ip6tables - avis. Évalué à 1. Dernière modification le 03 mai 2019 à 16:54.
Tout fonctionne sans, donc je garde ces règles pour mon usage de base. J'ai un autre set de règles autorisant :
[^] # Re: Avis
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1.
Et une petite chose que je ne comprend pas :
Pour transmission j'ai :
iptables -A OUTPUT -p udp --sport 51413 -j ACCEPT
J'avais par mégarde modifié en dport, et ça ne fonctionnait plus.
En revanche tout mes output http, https etc. fonctionnent avec du ouput --dport.
Que se passe-t-il ?!
Merci d'avance
# Avis
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1.
Bonjour !
Un petit avis sur la dernière version de mon iptables ci-dessus ?
Des optimisations ?
Pas d'oubli, bien sécurisé ?
Merci d'avance !
[^] # Re: Merci ! Encore quelques questions...
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1. Dernière modification le 26 avril 2019 à 07:46.
Ok, ça, ça me permet d'y voir plus clair quand l'utilité de ma démarche.
Ceci dit, comme je disais, l'utilité n'est pas ce qui m'intéresse, j'ai envie de répondre à ma curiosité, et à ma paranoïa dans une moindre mesure (plus exactement, sensation de sécurité).
Si configurer IPtables me permet de répondre à ces deux exigences, quand bien même ça ne serait pas utile d'un strict point de vue sécurité vu les conditions dans lesquelles j'utilise ce PC…
Mais je comprend parfaitement ce que tu me dis. Et ça m'aide grandement, parce que je me prennai bien la tête à vouloir tout régler au plus vite.
Vu qu'il n'y a pas de vraie utilité, et donc aucune urgence, au moins maintenant je me prendre mon temps.
[^] # Re: IP6tables
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1.
Merci !
Pas de pistes pour ip6tables ? j'avoue que je n'y comprend plus rien.
# IP6tables
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1. Dernière modification le 25 avril 2019 à 19:09.
Pour rappel, j'en suis à ceci :
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
// Autorise les connexions déjà établies et localhost
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
// TOR
iptables -A OUTPUT -p tcp -m tcp --dport 9050 -j ACCEPT
// DNS
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
// HTTP
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
// HTTPS
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
// Mail SMTP
// iptables -A INPUT -p tcp --dport 25 -j DROP
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
// iptables -A INPUT -p tcp --dport 587 -j DROP
// iptables -A OUTPUT -p tcp --dport 587 -j DROP
// Transmission
iptables -A INPUT -p udp --dport 51413 -j ACCEPT
iptables -A OUTPUT -p udp --dport 51413 -j ACCEPT
// NTP (horloge du serveur)
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
Qui me semble fonctionnel et minimal.
Sauf que le même ensemble de règles avec ip6tables en plus, tout fonctionne sauf smtp.
Merci d'avance.
NB : comment faire sur ce forum pour que # ne soit pas interpreté comme titre, afin de gagner en lisibilité ? Remplacé par // bien que ça ne fasse aucun sens, en attendant.
[^] # Re: Merci ! Encore quelques questions...
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1.
Bonne chance ahah !
Encore une petite question, tu me disais que iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT ne faisait pas de sens (established sur output).
Mais sans, qu'avec le input established, ça ne marche plus ! Plus d'accès au net.
Les deux sont donc bien nécessaires finalement ?
[^] # Re: Merci ! Encore quelques questions...
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1.
Parfait ! Merci encore !
Et petite question, maîtrises-tu par extension ip6tables ?
J'avais lu qu'il suffisait de transposer ses règles iptables. Mais juste avec iptables, smtp fonctionne, avec iptables + ip6tables, il ne fonctionne plus. Or je l'utilise pour m'envoyer des rapports type logwatch etc.
[^] # Re: Merci ! Encore quelques questions...
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1.
Merci bien !
Et donc, si je comprend bien, la règle established, elle, ne permettrai pas à un petit malin de faire la même chose ? Après tout, le port est finalement ouvert de même ?
[^] # Re: Merci ! Encore quelques questions...
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1.
A vrai dire, votre "conflit" m'est utile, sans ça ce thread n'avancerai pas autant, et je n'aurai pas appris autant de chose en aussi peu de temps ahah !
Merci encore, vraiment.
Donc si je comprend bien, la règle input established ne laisse passer que le retour des ports que j'ai autorisé, donc tout reste sécurisé ?
Du coup, la règle established que j'avais précisé dans le script initial pour transmission est des plus superflu!.
Je vais retravailler tout ça et vous pondrai une version finale ce soir.
Ce qui m'intrigue c'est que sur un autre forum, ainsi qu'un ami, m'ont dit "que tes règles ne servent à rien, sans ta ligne acceptant les established, rien ne passe". Commentaire à prendre en compte et possibilité de faire fonctionner le tout sans cette ligne, via une autre solution ? Ou on m'a juste embrouillé et commentaires à oublier ?
[^] # Re: Merci ! Encore quelques questions...
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1. Dernière modification le 25 avril 2019 à 13:34.
Je reviens à la charge, même si ça ne va pas plaire à tout le monde.
De là où j'en suis dans ma compréhension de tcp/ip et d'iptables, après avoir tout configuré en drop (mais si inutile pour output et forward, mais bref), un code minimal devrait suffire :
iptables -A INPUT -i lo -j ACCEPT
DNS
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
HTTP
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
HTTPS
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
Sauf que non. Ce que je ne comprend pas, c'est pourquoi sans les lignes :
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
rien ne fonctionne. Autoriser lo, dns, http et https devrait pourtant pouvoir suffire à accéder au net, de ce que je comprend. Non ?
Mes excuses, après ça je vous laisserai en paix jusqu'à lecture complète de ce que je suis sensé lire.
[^] # Re: Commencer par le début
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1.
Merci !
Je lis pas mal sur le sujet, mais j'avance à petit pas, et il me faut un but concret pour me motiver, d'où l'idée d'iptables sur une machine de bureau, avant un éventuel serveur une fois les bases des notions de réseaux acquises et la config de iptables, fail2ban et ce genre de chose maîtrisée. Juste source de motivation, et curiosité. Aussi, il y a quelque chose de rassurant à un pare-feu bien configuré pour un PC souvent utilisé en déplacement.
Ceci dit, je reviendrai sans doute poster un autre iptables avant d'avoir pleinement maîtrisé la doc de TCP/IP. Ne m'en veux pas, s'il te plait. Ahah.
Aussi, et parce que la qualité des sources comptent, auriez vous quelques liens et tutos à partager, peut-être mieux conçu que ce que j'ai ? (je suis entre openclassrooms et un cours d'un ami en info).
Merci encore.
# Merci ! Encore quelques questions...
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1. Dernière modification le 24 avril 2019 à 15:15.
Merci tout le monde !
Sincèrement, toutes ces infos me sont précieuses.
Il n'y a aucun intérêt, dans mon cas, à avoir un pare-feu, à part l'occasionnelle connexion à un réseau public ce genre de chose.
C'est de la pure curiosité. J'ai lu un article, puis j'ai voulu comprendre comme ça fonctionnait. Aussi, je n'exclu pas du tout d'avoir un serveur un jour, juste par… curiosité et pour quelques projets, donc pas nécessairement inutile non plus comme compétence.
Les torrents fonctionnent ! Mais on m'avait fait remarqué que sans mes deux lignes established, mes règles ne servaient à rien, et vrai que sans elles rien ne marche. Du coup, bien perdu ! Est-ce correct, ou ça ne l'est pas ?
J'avais bien vu related, et vu que je me suis amusé à tout essayé règle par règle, sans, tout marche. Donc j'ai laissé sans.
Donc à revoir :
1) La façon de loguer
2) plein de drop spécifiés inutiles vu que policy drop par défaut
3) quant au doublon established pour transmission… je ne ferai pas justement mieux de précsier established ligne par ligne, port par port, plutôt que toutes les autorisées.
Et.. je me tentais à faire de même avec ip6tables, vu qu'apparement je suis en ipv6… Sauf que je partait du principe qu'à règles identiques, tout marcherai de même. Sauf que nom, c'est l'envoi de mail via smtp qui ne fonctionne plus.
# Commencer par le début
Posté par redraven . En réponse au message IPtables -configuration. Évalué à 1.
Merci bien cimcim ! C'est ce que j'avais cru comprendre. Du coup, mon utilisation d'established reste sécurisée ? c'est mettre un new à cet endroit qui serait une jolie bêtise.
Bernez : aucun problème, comme je disais, je débute.
Je m’intéresse à iptables en parallèle de la lecture de plusieurs tutos/articles sur les réseaux, les protocoles etc.
Les premiers paragraphes sont du copier coller, oui. Et après lecture, je comprend parfaitement la partie sur les invalid, qui semble logique, un peu moins la partie avec les --tcp-flags (c'est ma lecture du moment, tout lire sur ce qui suis ce paramètre).
Pour la suite, par contre, j'ai passé des heures et des heures à tester chaque règle jusqu'à ce que firefox, transmission etc. fonctionne, avec le nombre de ligne minimal. Il me semblait avoir tout compris à ces paragraphes là, pourtant. J'ai fait du netstat et tcpdump pour savoir quel process, quel port etc.
Où se trouve les erreurs dans ce qui suis ?
Merci en tout cas !