Vous n'êtes pas identifié(e).
et la configuration que j'ai ajouter enfin du fichier de /etc/dnsmasq.conf
et j'ai activer l'ipv4 forwarding dans le fichier /etc/sysctl.conf
Voici toute ma liste de questions:
1) Comment sont gérées les interfaces réseau et les cartes wifi, car que l'on soit connecté en wifi ou en ethernet, la passerelle apparait toujours avec la même IP.
Ma passerelle est 192.168.2.254 pour mon wifi et 192.168.2.253 lorsque je suis connecté en ethernet.
Je suppose qu'ils ont créer un "Broadcast"? Si c'est bien cela chercher à avoir la même passerelle en wifi et en câblé va me coûté quelques heures de scripts supplémentaires, pour réussir à gérér l'ajout des nouvelles adresses mac qui voudront se connecté en wifi. voir ce lien très bien expliqué: https://wiki.debian.org/fr/BridgeNetworkConnections
Vu que je suis en dhcp pour la gestion du sous réseau, peut importe que les adresses des 2 passerelles soient différentes, ce qu'il compte, c'est que tout mon matériel soient visible sur le même réseau (et surtout aussi simple qu'une box normal pour ma chérie et les invités)
Pourriez vous me confirmer ce que je dis dans tout ce pavé?
2) Pourriez vous me valider tout les éléments que je peux activer/désactiver pour ma configuration de sysctl.conf, pour ajouter un peut de sécurité, désactiver totalement l'ICMP et ne pas activer l'IPV6.
La configuration de mon pare-feu actuellement, que j’essaie d'améliorer avec 2 exemples que j'estime sérieux:
https://geekeries.org/2018/04/logs-iptables/
http://www.canonne.net/linux/iptables/firewall.sh.php
3) Auparavant j'avais activé cette section dans mon parefeu, mais je nepense pas que cela soit à l'ordre du jour?
Merci d'avance
Dernière modification par dudux2 (06-04-2020 20:46:45)
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
iface wlan0 inet static
address 192.168.2.254
netmask 255.255.255.0
(...)
iface eth0 inet static
address 192.168.2.252
netmask 255.255.255.0
Configurer le même réseau IP sur deux interfaces indépendantes est une très mauvaise idée.
Comment sont gérées les interfaces réseau et les cartes wifi
Question trop vague.
Je suppose qu'ils ont créer un "Broadcast"?
Cette phrase ne veut rien dire.
ce qu'il compte, c'est que tout mon matériel soient visible sur le même réseau
Alors il faut regrouper les deux interfaces dans un pont au lieu de les configurer indépendamment.
Note que pour ponter l'interface wifi, il faudra d'abord la configurer en mode master (point d'accès). Dans cet ordre.
pour ajouter un peu de sécurité, désactiver totalement l'ICMP et ne pas activer l'IPV6.
Ridicule. Désactiver totalement ICMP n'ajoute pas de sécurité et casse le fonctionnement normal de TCP/IP.
Il vaut mieux montrer que raconter.
Hors ligne
dudux2 a écrit :
iface wlan0 inet static
address 192.168.2.254
netmask 255.255.255.0
(...)
iface eth0 inet static
address 192.168.2.252
netmask 255.255.255.0
Configurer le même réseau IP sur deux interfaces indépendantes est une très mauvaise idée.
Quel est le risque? Conflit d'IP?
dudux2 a écrit :
ce qu'il compte, c'est que tout mon matériel soient visible sur le même réseau
Alors il faut regrouper les deux interfaces dans un pont au lieu de les configurer indépendamment.
Note que pour ponter l'interface wifi, il faudra d'abord la configurer en mode master (point d'accès). Dans cet ordre.
J'en prends bonne note, j'ai déjà vu le principe sur divers tuto.
Créer un pont réseau entre ma carte wifi et ma carte ethernet implique forcément l'utilisation d'Ebtable? A priori les trames qui ont une adresse source non identifié par le point d'accès vont être rejeter comme l'explique ce lien: https://wiki.debian.org/fr/BridgeNetworkConnections
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
Quel est le risque? Conflit d'IP?
Routes conflictuelles. Ce n'est pas un risque, c'est un certitude. S'il y a plusieurs routes via des interfaces différentes pour la même destination, le noyau va en choisir une et ignorer les autres. La communication avec les machines connectées à l'interface d'une route ignorée sera donc impossible.
Créer un pont réseau entre ma carte wifi et ma carte ethernet implique forcément l'utilisation d'Ebtable
Non. Ebtables n'est utile que s'il faut faire du filtrage des trames ethernet pontées. Iptables peut filtrer les paquets IP pontés, si nécessaire.
A priori les trames qui ont une adresse source non identifié par le point d'accès vont être rejeter comme l'explique ce lien: https://wiki.debian.org/fr/BridgeNetworkConnections
Où exactement est-ce expliqué ?
Tu ne confondrais pas avec le pontage d'une interface wifi en mode managed (infrastructure), ce qui NE MARCHE PAS ?
Il vaut mieux montrer que raconter.
Hors ligne
/etc/dnsmasq.conf
/etc/dhcpcd.conf
/etc/hostapd/hostapd.conf
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
Merci d'avance!
Dans les 3/4 des tutos que l'on trouve, il est dit d'autoriser les connexions établies avant de tout mettre en DROP
Et au final, il propose un script comme celui-ci:
Du coup entre le manuel et les scripts, je suis un peut perdu...
Iptables refait le tri avant de rangés les règles dans ces tiroirs?
Dernière modification par dudux2 (07-04-2020 22:25:43)
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
Si j'ai bien compris, il faut au maximum évité d'utilisé RELATED, sauf pour l'icmp
Tu as mal compris. RELATED doit s'utiliser là où il est approprié.
Mon soucis c'est que tout les packets reste bloqué dans le "! --state INVALID"
Vous en pensez quoi?
Si tu ne montres pas le jeu de règles complet avec toutes les chaînes, ça va être difficile d'émettre un avis.
Il vaut mieux montrer que raconter.
Hors ligne
/etc/iptables/rules.v4
J'ai quelque chose qui me chiffonne, je n'ai pas encore installer fail2ban et lorsque j'active cette règle, j'ai des choses dans mes logs.
Sans Fai2Ban installé, je devrais rien avoir?
Vous avez une explication?
Pourquoi dans le fichier rules.v4, ma tabble RAW est positionné après la table MANGLE?
Une déclaration dans le mauvais ordre quelque part?
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
Dernière modification par raleur (08-04-2020 11:14:15)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par dudux2 (08-04-2020 11:43:19)
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
Oui je préfère travaillé sur le dernier que j'ai posté.
L'usine à gaz du message #8 ?
Il vaut mieux montrer que raconter.
Hors ligne
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
Il n'y a aucun démon dans ce script. iptables n'est pas un démon.
1) Ce n'est pas de la fragmentation TCP (on dirait plutôt segmentation) mais de la fragmentation IP.
2) Cette règle ne sert à rien puisque le suivi de connexion (conntrack) est activé par les correspondances "state" et la table "nat" et réassemble les fragments avant l'entrée dans la chaîne mangle/PREROUTING. De toute façon bloquer aveuglément les fragments serait une mauvaise idée.
Manque la gestion des types ICMP d'erreur qui doivent être acceptés dans l'état RELATED (destination-unreachable, time-exceeded, parameter-problem). Nécessaire pour le path MTU discovery et le retour de traceroute.
Redondance de l'état ESTABLISHED.
Les paquets retour seraient mieux gérés avec l'état ESTABLISHED.
1) Installer un paquet dans un script d'init, il faut oser ! Surtout avec des règles qui n'autorisent pas HTTP pour accéder aux miroirs, à moins d'avoir un miroir local sur le LAN.
2) iptables-persistent ne risque-t-il pas d'entrer en conflit avec ce script ?
3) Le message affiché est trompeur puisque l'action n'est pas la création du répertoire manquant mais l'installation du paquet iptables-persistent.
4) Si le répertoire n'existe pas, la fonction continue quand même et utilise ce répertoire inexistant -> erreur.
5) A quoi sert le test de présence du fichier iptables.rules.ipv4 puisque dans tous les cas on écrit dans le fichier rules.v4 ?
6) A quoi sert la commande touch puisque de toute façon le fichier va être créé par la redirection s'il n'existe pas ?
Il n'y a pas d'action "stop" alors que c'est obligatoire pour un script avec Default-Stop non vide.
Dernière modification par raleur (08-04-2020 13:11:19)
Il vaut mieux montrer que raconter.
Hors ligne
# Short-Description: Firewall deamon
# Description: Enable service provided by daemon.
Il n'y a aucun démon dans ce script. iptables n'est pas un démon.
En effet, j'ai repris mon ancien script, qui était lancé au démarrage du système auparavant, mais ce n'est plus le cas.
D’où le fait qu'il manque le stop à la fin.
J'ai nettoyé l'entête.
# Bloquer la fragmentation TCP :
$IPT -t mangle -A PREROUTING -f -j PRE_LOG_N_DROP
1) Ce n'est pas de la fragmentation TCP (on dirait plutôt segmentation) mais de la fragmentation IP.
2) Cette règle ne sert à rien puisque le suivi de connexion (conntrack) est activé par les correspondances "state" et la table "nat" et réassemble les fragments avant l'entrée dans la chaîne mangle/PREROUTING. De toute façon bloquer aveuglément les fragments serait une mauvaise idée.
J'ai supprimer la ligne pour la fragmentation IP
# Toutes les connexions qui sortent du LAN-Net sont acceptées
$IPT -t filter -A FORWARD -i $IFACE_BRDG -o $IFACE_INET -m state --state NEW,ESTABLISHED -j LOG_N_ACCEPT
$IPT -t filter -A FORWARD -i $IFACE_INET -o $IFACE_BRDG -m state --state ESTABLISHED -j LOG_N_ACCEPT
Manque la gestion des types ICMP d'erreur qui doivent être acceptés dans l'état RELATED (destination-unreachable, time-exceeded, parameter-problem). Nécessaire pour le path MTU discovery et le retour de traceroute.
J'ai rajouté l'état RELATED sur les 2 lignes.
# On permet toutes les liaisons firewall-LAN
$IPT -t filter -A OUTPUT -o $IFACE_BRDG -m state --state NEW,ESTABLISHED -j LOG_N_ACCEPT
$IPT -t filter -A INPUT -i $IFACE_BRDG -m state --state ESTABLISHED -j LOG_N_ACCEPT
#on permet toutes les liaisons LAN-firewall
$IPT -t filter -A INPUT -i $IFACE_BRDG -m state --state NEW,ESTABLISHED -j LOG_N_ACCEPT
$IPT -t filter -A OUTPUT -o $IFACE_BRDG -m state --state ESTABLISHED -j LOG_N_ACCEPT
Redondance de l'état ESTABLISHED.
Là je ne maîtrise pas assez (du tout) pour trouver la solution à la redondance...
Ici sur mon réseau local, je devrais sans doute ajouter l'état RELATED aussi? Pour l'ICMP et le FTP
# connexions Firewall-Internet (ping)
$IPT -t filter -A OUTPUT -p icmp --icmp-type echo-request -o $IFACE_INET -j LOG_N_ACCEPT
$IPT -t filter -A INPUT -p icmp --icmp-type echo-reply -i $IFACE_INET -j LOG_N_ACCEPT
# connexions Firewall-Internet (dns)
$IPT -t filter -A OUTPUT -p udp --dport 53 -o $IFACE_INET -j LOG_N_ACCEPT
$IPT -t filter -A INPUT -p udp --sport 53 -i $IFACE_INET -j LOG_N_ACCEPT
$IPT -t filter -A OUTPUT -p tcp --dport 53 -o $IFACE_INET -j LOG_N_ACCEPT
$IPT -t filter -A INPUT -p tcp --sport 53 -i $IFACE_INET -j LOG_N_ACCEPT
# connexions Firewall-Internet (ntp)
$IPT -t filter -A OUTPUT -p udp --dport 123 -o $IFACE_INET -j LOG_N_ACCEPT
$IPT -t filter -A INPUT -p udp --sport 123 -i $IFACE_INET -j LOG_N_ACCEPT
$IPT -t filter -A OUTPUT -p tcp --dport 123 -o $IFACE_INET -j LOG_N_ACCEPT
$IPT -t filter -A INPUT -p tcp --sport 123 -i $IFACE_INET -j LOG_N_ACCEPT
Les paquets retour seraient mieux gérés avec l'état ESTABLISHED.
C'est normalement corrigé dans le nouveau script...
fw_save ()
{
if [ ! -d "/etc/iptables/" ]; then
apt-get install iptables-persistent -y
#mkdir -p /etc/iptables/
echo "Le répertoire /etc/iptables/ à été créer!"
fi
if [ -e "/etc/iptables/iptables.rules.ipv4" ]; then
$IPT-save > /etc/iptables/rules.v4
else
touch /etc/iptables/rules.v4
$IPT-save > /etc/iptables/rules.v4
fi
}
1) Installer un paquet dans un script d'init, il faut oser ! Surtout avec des règles qui n'autorisent pas HTTP pour accéder aux miroirs, à moins d'avoir un miroir local sur le LAN.
2) iptables-persistent ne risque-t-il pas d'entrer en conflit avec ce script ?
3) Le message affiché est trompeur puisque l'action n'est pas la création du répertoire manquant mais l'installation du paquet iptables-persistent.
4) Si le répertoire n'existe pas, la fonction continue quand même et utilise ce répertoire inexistant -> erreur.
5) A quoi sert le test de présence du fichier iptables.rules.ipv4 puisque dans tous les cas on écrit dans le fichier rules.v4 ?
6) A quoi sert la commande touch puisque de toute façon le fichier va être créé par la redirection s'il n'existe pas ?
Ah oui, j'avoue que cela est de la grosse bidouille que j'avais oublié, que j'ai nettoyé.
Iptables-persistant est bien installé, donc j’exécute juste mon script avec l'action "test" et après un "start" puis "save" pour le rendre définitif et valide au prochain démarrage.
Ah oui je n'avais plus accès au HTTP(S) sur le serveur, c'est ajouter.
echo " - ${yellow}Usage: $0 {start|blockAllInput|restart|clear|test|list|status|save|restore|help}${NC}"
Il n'y a pas d'action "stop" alors que c'est obligatoire pour un script avec Default-Stop non vide.
Oui car je ne lance plus en automatique, donc le stop est inutile, mais c'est sûr tu ne pouvais pas le deviné...
Autres questions:
- Je me suis rendu compte que je ne recevais pas les logs de mes DROP, j'ai donc ajouter les chaînes de ma table FILTRE en DROP après tout mes ACCEPT pour pouvoir récupérer mes DROP dans les fichiers de logs.
- Ma politique de DROP au début ne devrait-elle pas être située après toutes mes règles en ACCEPT, cela me paraît plus logique!?
- Lorsque l'on à une politique en DROP, je suppose que faire un DROP sur les packets INVALID est inutile, que cela est fait automatiquement?
- J'ai trouvé cela sur le net, est-ce correcte au niveau de l'INPUT en udp qui serait inutile?
- Et si je compare avec mon code, son INPUT en tcp est en dport et moi en sport, qui à raison?
Mon fichier modifié:
Dernière modification par dudux2 (09-04-2020 07:26:20)
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
Manque la gestion des types ICMP d'erreur qui doivent être acceptés dans l'état RELATED (destination-unreachable, time-exceeded, parameter-problem). Nécessaire pour le path MTU discovery et le retour de traceroute.
J'ai rajouté l'état RELATED sur les 2 lignes.
Je ne parlais que de trois types ICMP, et du coup tu autorises TOUS les paquets dans l'état RELATED à travers le routeur !
Là je ne maîtrise pas assez (du tout) pour trouver la solution à la redondance...
Tu vois bien que par exemple dans ces deux règles
La première règle n'apporte rien par rapport à la seconde, donc elle est redondante et peut être supprimée.
Ou bien l'état ESTABLISHED est redondant dans la seconde règle est peut en être retiré puisque déjà accepté dans la première.
Ici sur mon réseau local, je devrais sans doute ajouter l'état RELATED aussi? Pour l'ICMP et le FTP
Pour les trois types ICMP mentionnés plus haut, oui.
Pour FTP, la gestion de l'état RELATED est utile seulement si tu gères le protocole FTP avec le module nf-conntrack-ftp et les règles CT --helper qui vont avec. Sinon les connexions de données FTP seront vues comme des connexions indépendantes commençant par l'état NEW.
Si tu vois des paquets ICMP echo-reply dans l'état NEW, tu me fais signe.
L'ajout de la condition sur l'état ESTABLISHED bouche la faille. Cette règle n'est pas inutile : sans elle, tu bloques les paquets UDP de réponse DNS.
- Ma politique de DROP au début ne devrait-elle pas être située après toutes mes règles en ACCEPT, cela me paraît plus logique!?
Non. La politique par défaut d'une chaîne n'est pas une règle, sa place dans la chaîne ne dépend pas de l'ordre des commandes. Elle s'applique toujours aux paquets qui atteignent la fin de la chaîne sans avoir été acceptés ou bloqués par aucune règle.
- Lorsque l'on à une politique en DROP, je suppose que faire un DROP sur les packets INVALID est inutile, que cela est fait automatiquement?
C'est à ça que sert la politique par défaut : définir le sort des paquets arrivés en fin de chaîne. Mais si tu veux des logs, il faut des règles.
- J'ai trouvé cela sur le net, est-ce correcte au niveau de l'INPUT en udp qui serait inutile?
- Et si je compare avec mon code, son INPUT en tcp est en dport et moi en sport, qui à raison?
Toi, pour les règles TCP. TCP ne fonctionne pas différemment avec le protocole DNS qu'avec les autres protocoles.
--dport en INPUT serait utile si la machine faisait office de serveur DNS public, ce qui ne semble pas être le cas.
En tout cas ça n'accepte pas les réponses reçues (qui ont le port source 53) aux requêtes DNS émises.
Il vaut mieux montrer que raconter.
Hors ligne
Debian testing, nvidia 980 gtx sli, cm asurock 16 gb ram cpu i7 4,2 ghz
Hors ligne
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
Dernière modification par dudux2 (10-04-2020 12:51:17)
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
J'aurais pu simplifier encore plus en autorisant les 3 types d'ICMP pour toute les interfaces, mais pour les même raisons ci-dessus, autant restreindre au interface utiliser?
Mon script:
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
Pour mes pauvre connaissance j'ajouterai:
Des regles qui autorise que les adresse mac qui son sur une liste pour le wifi c'est une petite securiter en plus. c est pas inviolable mai sa complique quand meme la tache.
La liste des dns autoriser wifi et lan , certaine application ce gène pas pour aller ou elle veule. vu que tu n'utilise pas de serveur dns c'est pas forcément possible.
Oui je réfléchissais à un petit script qui activerais le WPS via un bouton poussoir sur une entrée du RPI.
Bloquer l'ipv6 contrairment a ce qui ce dit, toute les application a ce jour ou celle que j'utilise 1 seul peux l'utiliser. donc bon .... l'icmp est utile mai pas indispensable pour l'ipv4 mai obligatoir pour l'ipv6.
j'aurai ajouter des limites de tentative par heure, de meme, pour tout ce que tu log j'ai pas vu de limitation (j'ai aussi lu en traver le gros pavé...) le risque c'est le fichier de log qui devien enorme... etc.
Je gère les logs avec des limites en bas de ma fonction start et j'ai activé la compression dans logrotate.d, pour le moment je les laisse causé beaucoup pour contrôler le fonctionnement.
J'ai aussi monter ma box mai sous debian. et fait une page dans wiki que tu peux peut etre ,et surment, ameliorer. c'est pas parfait mai ça peut inspirer
Je vais regardé cela, c'est toujours intéressant!
Attention utilise iptable-save, et pas ton script pour le lancer car le temp de la lecture les paquet peuve passer si la machine a peux de puissance. (sa ma fait le gag et valu un post)
pour le reste je laisse a ceux qui connaisse mieux que moi le reseaux.
Mon script sert seulement à testé mes règles pendant x temps et "iptables-restore" mes anciennes règles au bout de x temps.
Mais j'utilise bien iptables-save pour sauvegarder mes règles et iptables permanent pour qu'elles se lancent au démarrage.
Fait toi plez.
Oh oui je m'éclate!
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
Je savais pas que l'on pouvait factoriser les 3 règles dans une chaine comme cela
Il y a deux gros soucis dans ta factorisation.
1) Dans la section "Gestion de la passerelle", les règles envoient les paquets RELATED dans la chaîne LOG_N_ACCEPT au lieu de la chaîne LOG_ICMP_N_ACCEPT.
2) La chaîne LOG_ICMP_N_ACCEPT ne journalise que les trois types ICMP mais accepte tous les paquets qu'elle reçoit.
Il y a aussi des soucis plus mineurs mais que je veux quand même mentionner.
3) Le nom de la chaîne LOG_ICMP_N_ACCEPT contient "ICMP" alors qu'en fait tu y envoies tous les paquets qui ont l'état RELATED. Ce n'est pas très cohérent.
4) Le nom de la chaîne LOG_ICMP_N_ACCEPT contient "ACCEPT" alors que tous les paquets qui y vont (même si tu n'y envoies que les paquets ICMP RELATED) n'ont pas vocation à être acceptés.
5) Tu n'es pas obligé de faire le LOG directement dans cette chaîne, tu peux très bien y utiliser les chaînes LOG_N_ACCEPT et LOG_N_DROP.
J'ai vu cela sur le net, c'est mieux de rajouté la source et la destination? Plus on est restrictif, je suppose, plus l'on est sécurisé en cas d'attaque...
En l'occurrence il s'agit de trafic émis par et à destination de la machine elle-même.
Plus on est restrictif, plus on court le risque de blocages abusifs pouvant causer des dysfonctionnements.
Déjà, c'est bien d'avoir autorisé tout le préfixe 127.0.0.0/8 et pas seulement l'adresse 127.0.0.1. Mais ce ne sont pas les seules adresses pouvant être utilisées sur l'interface de loopback : toutes les adresses de toutes les interfaces de la machines le peuvent aussi.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par dudux2 (12-04-2020 11:17:43)
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne
Je garde mes logs séparer dans des fichiers pour le moment
D'accord mais ça n'empêche pas de factoriser ACCEPT et LOG avec le préfixe "ACTION7=ACCEPT-ICMP" dans une nouvelle chaîne LOG_ACCEPT_ICMP.
Je n'aurais pas mis "ACCEPT" dans le nom de la chaîne FILTRE_ICMP_TYPE_N_ACCEPT, car tout ce qui y entre n'est pas forcément accepté.
Dans une des règles qui appellent la chaîne FILTRE_ICMP_TYPE_N_ACCEPT, tu as ajouté le critère du protocole ICMP
mais pas dans les autres :
Pourquoi cette incohérence ?
Certes pour le moment ça ne fait aucune différence puisque la chaîne ne contient que des règles pour les paquets ICMP, mais ça pourrait changer à l'avenir.
A mon avis il faut que tu choisisses : est-ce que la chaîne a pour but de filtrer tous les paquets dans l'état RELATED ou seulement les paquets ICMP ? Dans un cas comme dans l'autre, il faudrait mettre les règles appelantes et le nom de la chaîne en conformité avec ce but.
Pourquoi ne pas contrôler l'état (avec -m state --state NEW,ESTABLISHED) sur la machine locale et autoriser aussi les 3 types d' ICMP?
Tu veux dire sur l'interface de loopback ? Parce que les paquets ICMP dans l'état RELATED et les paquets arbitraires dans l'état INVALID ne peuvent être émis que par le noyau ou un processus privilégié de la machine. Si tu ne leur fais pas confiance, tout ceci ne sert pas à grand chose. Et aussi parce que le filtrage sur l'interface de loopback est un peu particulier puisque chaque paquet passe successivement dans OUTPUT et INPUT.
Pour les interfaces ponté, elles sont transparentes au niveau des règles? Elles héritent des autorisations du pont?
Normalement oui, et il n'y a aucun filtrage du trafic ponté qui passe directement entre les deux interfaces du pont.
Il y a possibilité de donner des règles directement à ces interfaces (Juste au cas ou je voudrais des règles différentes pour le wifi et le réseau câblé (comme par exemple interdire l’accès ssh et le hhtp en wifi)
Avec le module br-netfilter (ou le module bridge avant Stretch), il y avait la possibilité d'appliquer les règles arptables, iptables et ip6tables aux paquets pontés. Il y avait aussi la possibilité d'utiliser des règles ebtables (mais ça ne gère pas l'état NEW,ESTABLISHED...). Mais avec nftables qui est censé remplacer tout ça, je ne sais pas si ça marche encore.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par dudux2 (12-04-2020 18:34:34)
Petit projet d’une box internet 4G avec un rpi3b+
Hors ligne