La Fibre
Datacenter et équipements réseaux => Routeurs => 
OpenWrt => Discussion démarrée par: basilix le 06 août 2024 à 18:19:59
-
Introduction
Une capture réseau affiche que mes paquets envoient des valeurs erronées dans certaines options. J'aurais voulu récupérer le code hexadécimal contenu dans certaines options en analysant
le trafic envoyé par la Livebox sur le réseau Orange. En effet, je n'ai pas la même Livebox que dans le tutoriel OpenWrt.
TLDR; (Too Long Didn't Read!!) (https://lafibre.info/openwrt/routeur-en-mode-pont-pour-capturer-le-trafic-orange/msg1082541/#msg1082541)
Piste à explorer
C'est facile de charger une image alternative de micrologiciel grâce à une carte mémoire. Mais je suis novice et j'appréhende sur la mise en œuvre. Le mieux serait de pouvoir confirmer sur la
façon de faire.
J'envisageais de rediriger le trafic au niveau de la couche liaison (Ethernet) via nftables. Selon le wiki, on peut dupliquer les trames non modifiées vers une autre interface au crochet ingress
d'une table de la famille netdev. Je suppose que deux ports du commutateur seront connectés respectivement à ma station et à la Livebox. Les trames dupliquées seront envoyées sur
l'interface correspondant au port du commutateur branché à ma station. Et mon module optique inséré dans la cage SFP de mon routeur fera la liaison optique vers le réseau Orange.
(https://lafibre.info/images/materiel/202408_openwrt_nf-hooks.webp)
Description de mon problème
Je n'ai aucune expérience et je ne sais pas si cela est réalisable... Il faudrait que je puisse recevoir les trames dupliquées sur ma station sans pour autant produire des brèches de sécurité. Le principe
est encore flou dans mon esprit. L'idée serait de faire abstraction de ma station et d'envoyer les trames à travers un pont reliant l'interface du réseau Orange à celle de la Livebox.
Comment empêcher que des paquets soient redirigés vers le routeur en mode pont ? Pour éviter que le trafic externe soit détourné en vue d'attaquer mon routeur. Est-il nécessaire de dupliquer les trames
ou faut-il les capturer via un processus tcpdump, localement sur le routeur ? Comment gérer les trames dupliquées ?
-
Les paquets du réseau local transitent par un pont dans le boîtier Internet. Cela peut paraître évident. Les stations situées sur le même réseau
peuvent communiquer sans routage grâce au commutateur intégré dans le boîtier Internet. Un commutateur Ethernet est un synonyme de pont.
Néanmoins, ce pont est transparent pour l'utilisateur. On dit de se connecter à l'adresse IP du routeur et non pas à l'adresse IP de l'interface du
pont. Puis d'expliquer que n'importe quel port du commutateur peut recevoir une trame dont l'adresse Ethernet de destination est celle de la carte
réseau reliée au commutateur elle-même associée à l'adresse IP de la passerelle définie dans les paramètres réseaux des stations.
Je précise car cela convoie l'impression que les paquets passent directement par le crochet prerouting et non indirectement par les crochets
prerouting bridge, input bridge et prerouting. N'hésitez surtout pas à me dire si je me trompe !
-
Je précise car cela convoie l'impression que les paquets passent directement par le crochet prerouting et non indirectement par les crochets
prerouting bridge, input bridge et prerouting. N'hésitez surtout pas à me dire si je me trompe !
peut être toquer un coup à la porte des forums openwrt pour demander aux experts dans le meilleur anglais ;)
-
Bonne idée !
Je vais lire le fil de discussion à propos de mon commutateur GS108Tv3. (https://forum.openwrt.org/t/netgear-gs108tv3-gs110tpv3-gs110tpp-switch-support/72510) Cela ne fait que 97 posts à lire.
[09:00] Je vais l'installer sur mon commutateur pour voir. Mais OpenWrt va probablement retirer le support Realtek dans la prochaine version (https://github.com/openwrt/openwrt/pull/16052).
-
Voici la configuration OpenWrt par défaut (v23.05.4) d'un commutateur Netgear GS108Tv3.
root@OpenWrt:~# uci export network
package network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd32:2ebf:11a8::/48'
config device 'switch'
option name 'switch'
option type 'bridge'
option macaddr '39:e4:84:7a:d0:60'
config bridge-vlan 'lan_vlan'
option device 'switch'
option vlan '1'
option ports 'lan1 lan2 lan3 lan4 lan5 lan6 lan7 lan8'
config device
option name 'switch.1'
option macaddr '39:e4:84:7a:d0:60'
config interface 'lan'
option device 'switch.1'
option proto 'static'
option ipaddr '192.168.1.4'
option netmask '255.255.255.0'
option ip6assign '60'
root@OpenWrt:~# uci export dhcp
uci: Entry not found
root@OpenWrt:~# uci export firewall
package firewall
config defaults
option syn_flood '1'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
root@OpenWrt:~# nft list ruleset
table inet fw4 {
chain input {
type filter hook input priority filter; policy drop;
iifname "lo" accept comment "!fw4: Accept traffic from loopback"
ct state established,related accept comment "!fw4: Allow inbound established and related flows"
tcp flags syn / fin,syn,rst,ack jump syn_flood comment "!fw4: Rate limit TCP syn packets"
iifname "switch.1" jump input_lan comment "!fw4: Handle lan IPv4/IPv6 input traffic"
jump handle_reject
}
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept comment "!fw4: Allow forwarded established and related flows"
iifname "switch.1" jump forward_lan comment "!fw4: Handle lan IPv4/IPv6 forward traffic"
jump handle_reject
}
chain output {
type filter hook output priority filter; policy accept;
oifname "lo" accept comment "!fw4: Accept traffic towards loopback"
ct state established,related accept comment "!fw4: Allow outbound established and related flows"
oifname "switch.1" jump output_lan comment "!fw4: Handle lan IPv4/IPv6 output traffic"
}
chain prerouting {
type filter hook prerouting priority filter; policy accept;
iifname "switch.1" jump helper_lan comment "!fw4: Handle lan IPv4/IPv6 helper assignment"
}
chain handle_reject {
meta l4proto tcp reject with tcp reset comment "!fw4: Reject TCP traffic"
reject comment "!fw4: Reject any other traffic"
}
chain syn_flood {
limit rate 25/second burst 50 packets return comment "!fw4: Accept SYN packets below rate-limit"
drop comment "!fw4: Drop excess packets"
}
chain input_lan {
jump accept_from_lan
}
chain output_lan {
jump accept_to_lan
}
chain forward_lan {
jump accept_to_wan comment "!fw4: Accept lan to wan forwarding"
jump accept_to_lan
}
chain helper_lan {
}
chain accept_from_lan {
iifname "switch.1" counter packets 665 bytes 56128 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
}
chain accept_to_lan {
oifname "switch.1" counter packets 176 bytes 14200 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
}
chain input_wan {
meta nfproto ipv4 udp dport 68 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCP-Renew"
icmp type echo-request counter packets 0 bytes 0 accept comment "!fw4: Allow-Ping"
meta nfproto ipv4 meta l4proto igmp counter packets 0 bytes 0 accept comment "!fw4: Allow-IGMP"
meta nfproto ipv6 udp dport 546 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCPv6"
ip6 saddr fe80::/10 icmpv6 type . icmpv6 code { mld-listener-query . no-route, mld-listener-report . no-route, mld-listener-done . no-route, mld2-listener-report . no-route } counter packets 0 bytes 0 accept comment "!fw4: Allow-MLD"
icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply, nd-router-solicit, nd-router-advert } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Input"
icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, parameter-problem . admin-prohibited, nd-neighbor-solicit . no-route, nd-neighbor-advert . no-route } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Input"
jump reject_from_wan
}
chain output_wan {
jump accept_to_wan
}
chain forward_wan {
icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Forward"
icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, parameter-problem . admin-prohibited } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Forward"
meta l4proto esp counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: Allow-IPSec-ESP"
udp dport 500 counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: Allow-ISAKMP"
jump reject_to_wan
}
chain accept_to_wan {
}
chain reject_from_wan {
}
chain reject_to_wan {
}
chain dstnat {
type nat hook prerouting priority dstnat; policy accept;
}
chain srcnat {
type nat hook postrouting priority srcnat; policy accept;
}
chain srcnat_wan {
meta nfproto ipv4 masquerade comment "!fw4: Masquerade IPv4 wan traffic"
}
chain raw_prerouting {
type filter hook prerouting priority raw; policy accept;
}
chain raw_output {
type filter hook output priority raw; policy accept;
}
chain mangle_prerouting {
type filter hook prerouting priority mangle; policy accept;
}
chain mangle_postrouting {
type filter hook postrouting priority mangle; policy accept;
}
chain mangle_input {
type filter hook input priority mangle; policy accept;
}
chain mangle_output {
type route hook output priority mangle; policy accept;
}
chain mangle_forward {
type filter hook forward priority mangle; policy accept;
}
}
Le seul truc bizarre c'est l'affichage de noms symboliques erronés pour les codes ICMPv6.
icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, parameter-problem . admin-prohibited } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Forward"
root@OpenWrt:~# nft -n list chain inet fw4 input_wan
chain input_wan {
meta nfproto 2 udp dport 68 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCP-Renew"
icmp type 8 counter packets 0 bytes 0 accept comment "!fw4: Allow-Ping"
meta nfproto 2 meta l4proto 2 counter packets 0 bytes 0 accept comment "!fw4: Allow-IGMP"
meta nfproto 10 udp dport 546 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCPv6"
ip6 saddr fe80::/10 icmpv6 type . icmpv6 code { 130 . 0, 131 . 0, 132 . 0, 143 . 0 } counter packets 0 bytes 0 accept comment "!fw4: Allow-MLD"
icmpv6 type { 1, 3, 128, 129, 133, 134 } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Input"
icmpv6 type . icmpv6 code { 2 . 0, 4 . 0, 4 . 1, 135 . 0, 136 . 0 } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Input"
jump reject_from_wan
}
-
Donc cela confirme ce que je pensais.
L'interface réseau du commutateur est un pont intégré dans le micrologiciel. Même si l'affirmer revient à enforcer des portes ouvertes. Néanmoins, vu que je manque
de connaissances, je trouve que c'est un point de départ.
Le commutateur a une interface WAN non configurée, probablement pour effectuer les mises à niveau du micrologiciel. Cela équivaudrait en quelque sorte à un pare-feu désactivé pour
les stations du réseau local.
chain accept_from_lan {
iifname "switch.1" counter packets 665 bytes 56128 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
}
chain accept_to_lan {
oifname "switch.1" counter packets 176 bytes 14200 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
}
Par contre, il n'y a aucun filtrage au niveau de la couche pont (https://wiki.nftables.org/wiki-nftables/index.php/Bridge_filtering).
-
Je crois que j'ai trouvé un schéma simplifié.
Convertir mon routeur en mode pont (cage SFP). Envoyer les trames dupliquées vers ma station (mise en mirroir). Wireshark pourra capter ces trames pour les analyser (mode promiscuité).
La grande inconnue est de savoir si la Livebox émet ses paquets sur son port RJ45 lorsque le port fibre n'est pas branché.
-
Je sèche.
J'aurais souhaité désactiver totalement IPv4 et IPv6.
root@OpenWrt:/# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
inet6 fe80::5893:27ff:fe5b:bcee/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether aa:29:34:93:94:2c brd ff:ff:ff:ff:ff:ff
4: wan@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
5: lan1@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
6: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
7: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
8: lan4@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
9: sfp2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
10: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 34:4f:43:62:70:00 brd ff:ff:ff:ff:ff:ff
11: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 34:4f:43:62:70:00 brd ff:ff:ff:ff:ff:ff
root@OpenWrt:/# uci export network
package network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1/8'
option ip6addr '::1/128'
config device 'switch'
option name 'switch'
option type 'bridge'
list ports 'eth1'
list ports 'sfp2'
list ports 'wan'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
L'objectif est de configurer un pare-feu transparent (https://wiki.nftables.org/wiki-nftables/index.php/Bridge_filtering#Example:_Stateful_bridge_firewall). Cela ne correspond pas vraiment au type de pare-feu (https://openwrt.org/docs/guide-user/firewall/fw3_configurations/bridge) tel que sur le wiki OpenWrt ; je ne crois pas qu'il soit nécessaire de créer les interfaces wan et lan comme mentionné.
-
La commande ci-dessous semble désactiver IPv6.
root@OpenWrt:/# sysctl -w net.ipv6.conf.all.disable_ipv6='1'
-
Par contre, le routeur n'a pas d'horloge matérielle et se met à l'heure via NTP. C'est sûrement problématique sans interface réseau avec une adresse, non ?
-
je crois que personne n'a compris ce que tu essaies de faire. Si on s'en remet au titre du topic, tu essaies de capturer le trafic de ton routeur. il y a tcpdump pour ca.
-
J'exprime mal ma pensée. Non, je veux placer un équipement réseau entre le réseau Orange et la Livebox pour analyser les flux de la Livebox.
Or, seul mon routeur peut intégrer un module SFP permettant de réaliser la jonction avec le réseau optique Orange. Donc, je charge un
micrologiciel OpenWrt adapté pour que l'appareil se comporte comme un commutateur Ethernet (non administrable) disposant d'un module SFP.
Je suis persuadé que l'on peut convertir l'appareil ayant auparavant un rôle de routeur en un commutateur en le configurant en mode pont.
Mais il ne faut pas le rendre apparent sur l'Internet pour des raisons évidentes de sécurité. Cet appareil fait intermédiaire entre les équipements
Orange et la Livebox tout en filtrant le trafic corrélé à la Livebox afin d'être dupliqué vers ma station (mise en miroir). C'est un pare-feu transparent.
L'idée est aussi d'éviter que le trafic venant de l'extérieur parvienne au mauvais endroit. Comme par exemple être redirigé vers ma station.
Je précise que la conversion du routeur en commutateur n'est fait que pour durer temporairement, de façon ponctuelle.
-
pour analyser les flux de la Livebox.
Qu'espères-tu y découvrir ou "filtrer" ?
je crois que personne n'a compris ce que tu essaies de faire.
Et surtout un sujet qui part en monologue. N'as-tu pas un bloc-note plutôt que ce forum qui devrait intervenir qu'après le ramassage de tes pensées ?
-
J'exprime mal ma pensée. Non, je veux placer un équipement réseau entre le réseau Orange et la Livebox pour analyser les flux de la Livebox.
Or, seul mon routeur peut intégrer un module SFP permettant de réaliser la jonction avec le réseau optique Orange. Donc, je charge un
micrologiciel OpenWrt adapté pour que l'appareil se comporte comme un commutateur Ethernet (non administrable) disposant d'un module SFP.
Je suis persuadé que l'on peut convertir l'appareil ayant auparavant un rôle de routeur en un commutateur en le configurant en mode pont.
Mais il ne faut pas le rendre apparent sur l'Internet pour des raisons évidentes de sécurité. Cet appareil fait intermédiaire entre les équipements
Orange et la Livebox tout en filtrant le trafic corrélé à la Livebox afin d'être dupliqué vers ma station (mise en miroir). C'est un pare-feu transparent.
L'idée est aussi d'éviter que le trafic venant de l'extérieur parvienne au mauvais endroit. Comme par exemple être redirigé vers ma station.
Je précise que la conversion du routeur en commutateur n'est fait que pour durer temporairement, de façon ponctuelle.
En tant que novice, je comprends que tu veux l'équivalent d'un port mirroring de switch (couche 2)?
https://community.fs.com/fr/article/port-mirroring-explained-basis-configuration-and-fa-qs.html
-
@Steph : C'est exact.
@ppn_sd : Je me suis sûrement mal exprimé. Le fil s'est transformé en monologue car cela a suivi le fil de ma pensée.
-
ok j'ai compris. Tu essaies avec openwrt, de faire un switch administrable avec port mirroring.
peut etre que cette video peut t'aider :
https://www.youtube.com/watch?v=yCV-08tSwe8
-
@rooot :
Je n'ai plus vraiment besoin d'aide. Au départ, j'avais besoin d'un coup de pouce pour clarifier le cheminement à prendre.
Par rapport à la vidéo, il y a plusieurs choses qui ne correspondent pas. Comme je souhaite analyser le trafic de la Livebox il ne faut pas faire de filtrage VLAN.
Je ne veux pas que le commutateur soit joignable, donc aucune adresse IP. La fonctionnalité de port-mirroring (mise en mirroir) peut être réalisé il me semble
grâce à nftables. Cela ne me posera pas de problème insurmontable car je sais comment produire une image OpenWrt personnalisée et il me semble que je
dispose des notions pour le faire.
-
Le routeur en mode pont (a.k.a. commutateur) est fonctionnel en définissant une adresse statique à l'interface du pont. Les adresses MAC peuvent être différentes ou identiques, peu importe.
-
En fait, nul besoin de définir une adresse statique pour l'interface du pont. J'avais lu partiellement le texte ci-dessous en passant des mots et eu une signification à l'inverse de ce que cela voulait dire.
If an interface section has no protocol defined (not even none ), the other settings are completely ignored. The result is that, if the interface section is mentioning a physical network interface (i.e. eth0),
this will be down even if a cable is connected (with proto 'none' the interface is up).
Source : Network configuration (Wiki OpenWrt) (https://openwrt.org/docs/guide-user/network/network_configuration#section_interface)
config interface 'switch'
option device 'switch'
option proto 'none'
Comme je l'ai dit auparavant, ne pas définir l'interface ne fonctionnera pas. Néanmoins spécifier qu'une interface n'a pas de protocole fonctionne !!
-
Il ne reste plus qu'à savoir s'il faudrait définir une nouvelle interface : wan.
Remarque : On retrouve malgré tout une adresse locale au lien.
root@OpenWrt:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
inet6 fe80::5c93:27ff:fe5b:bcee/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master switch state DOWN qlen 1000
link/ether aa:29:34:93:94:2c brd ff:ff:ff:ff:ff:ff
4: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master switch state UP qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
5: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch state LOWERLAYERDOWN qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
6: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch state LOWERLAYERDOWN qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
7: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch state LOWERLAYERDOWN qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
8: lan4@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master switch state UP qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
9: sfp2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch state LOWERLAYERDOWN qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
10: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 34:4f:43:62:70:00 brd ff:ff:ff:ff:ff:ff
11: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 34:4f:43:62:70:00 brd ff:ff:ff:ff:ff:ff
12: switch: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 5a:93:27:5b:bc:ee brd ff:ff:ff:ff:ff:ff
inet6 fe80::5c93:27ff:fe5b:bcee/64 scope link
valid_lft forever preferred_lft forever
Remarque : Il semble que l'on puisse désactiver IPv6 en ajoutant les lignes suivantes dans le fichier /etc/sysctl.conf.
# Defaults are configured in /etc/sysctl.d/* and can be customized in this file
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
Au démarrage, j'observe que l'interface eth0 génère une IPv6 locale au lien. L'utilisation de la commande sysctl -p semble déclencher instantanément « l'effacement de l'adresse ».
Il m'a aussi semblé qu'elle disparaissait automatiquement passé un certain délai (à vérifier). Lorsque je redémarre l'appareil, cela reconfigure une IPv6 locale au lien (le cycle se répète).
# Defaults are configured in /etc/sysctl.d/* and can be customized in this file
net.ipv6.conf.switch.disable_ipv6 = 1
En désactivant explicitement l'interface du pont (que j'ai dénommée switch), l'interface eth0 continue de génèrer une adresse locale au lien. Toutefois, l'appareil ne répond plus au requête ICMPv6 echo.
Je ne capte pas tout ; mais cela me convient parfaitement pour le moment : l'interface du pont n'a pas d'adresse IP et l'appareil semble être transparent sur le réseau.
-
L'adresse locale au lien n'aura aucune incidence sur ce que tu veux faire et pourra au contraire t'être utile. Une connexion SSH sur une LLA est possible.
-
@ppn_sd :
C'est le concept de pont filtrant ou pare-feu transparent (bridge firewall).
The following example shows how to deploy a stateful bridge firewall, this assumes the bridge interface has no IP address.
Source : Bridge filtering (nftables.org) (https://wiki.nftables.org/wiki-nftables/index.php/Bridge_filtering#Example:_Stateful_bridge_firewall)
Un pont filtrant est un équipement réseau. Le pont filtrant est un pont, donc il fonctionne en couche 2 du modèle OSI (liaison de données).
Il a la possibilité de filtrer les trames en se basant sur des caractéristiques de la trame tel que MAC Address source ou destination,
type de protocole de niveau 3 transporté, longueur de la trame. Il peut être invisible au niveau 3 car il peut ne pas être administrable
via IP.
Source : Pont filtrant (article Wikipédia) (https://fr.wikipedia.org/wiki/Pont_filtrant)
-
Il peut être invisible au niveau 3 car il peut ne pas être administrable
via IP.
Ce qui est assez différent de : il doit être invisible au niveau 3 car il ne doit pas être administrable par LL.
-
@ppn_sd :
Mon pont n'aura pas d'adresse IP. Je peux l'administrer par son interface UART via un adaptateur USB vers TTL.
Note : Actuellement, je n'ai pas intégré le pare-feu OpenWrt firewall4 dans l'image du micrologiciel par simplicité.
#!/bin/sh /etc/rc.common
START=19
start() {
nft -f /etc/nftables.conf
}
stop() {
nft flush ruleset
}
flush ruleset
table bridge filter {
chain forward {
type filter hook forward priority filter; policy drop;
ether type ip tcp dport 22 drop
ether type arp accept
}
}
Il faut que je teste. L'objectif sera à terme de pouvoir dupliquer le trafic de la Livebox et bloquer le trafic relatif à ma station ne provenant pas du port lié à la Livebox et allant au port SFP.
-
Il n'y a que le pont qui fonctionne. Le filtrage ne fonctionne pas.
Bizarre... je ne comprends pas.
-
Je crois que mon hypothèse de départ est fausse. (https://lafibre.info/openwrt/routeur-en-mode-pont-pour-capturer-le-trafic-orange/msg1082027/#msg1082027)
En effet, je ne vois aucun flux vers le port 22 en activant nftrace dans nftables. De plus, je vois beaucoup de paquets passant par le crochet prerouting de
la couche IP alors qu'aucun paquet ne passe par le crochet forward de la couche Bridge (pont).
Je pense que je mélange plusieurs concepts associés : DSA (distributed switch architecture), commutateur matériel, pont réseau. En conséquence, je vais plutôt
repartir en me basant sur les deux cartes réseaux de la carte-mère du routeur : filtrer à la jonction de deux réseaux « wan » et « lan ».
-
Il faut regarder au microscope pour y comprendre quelque chose à ce système DSA !
On a un divers circuits intégrés complémentaires commutateur (C.I. PHYs), MAC. Le pilote Linux de l'interface Ethernet de gestion pilote le contrôleur Ethernet MAC.
Lequel est connecté au commutateur via une interface HSGMII (https://en.wikipedia.org/wiki/Media-independent_interface). On est à la croisée des chemins entre l'électronique et l'informatique. La technologie DSA repose sur
une fonction incorporée dans le circuit intégré qui forme le commutateur. Les trames du commutateur sont envoyés au contrôleur Ethernet, que l'on a choisi d'appeler
« cpu » ou « master ». Par extension, le pilote Linux du contrôleur est appelé « master network device » (dispositif réseau maître) pour faire magiquement apparaître
une interface réseau maître, a.k.a. master interface (e.g. eth0). De même, la puce commutateur peut intégrer des tag dans les trames afin d'aider l'interface de gestion.
De là, on peut créer de nouvelles interfaces esclaves (slave interfaces) qui vont se charger chacune de « suivre » les trames d'un port en façade (relié électroniquement
au commutateur).
Sources
Distributed Switch Architecture (https://www.kernel.org/doc/html/v5.9/networking/dsa/dsa.html)
DSA switch configuration from userspace (https://www.kernel.org/doc/html/v5.9/networking/dsa/configuration.html)
-
Je ne suis pas certain de vraiment bien saisir les choses.
Example: Stateful bridge firewall
The following example shows how to deploy a stateful bridge firewall, this assumes the bridge interface has no IP address.
Assuming a bridge with two ports, eth0 and eth1.
- A desktop computer is connected to bridge port eth0
- A web server (with SSH for remote administrador) is connected to bridge port eth1
- Uplink is bridge port eth2
The following policy allows for the desktop computer and the web server to initiate any connection. From the outside:
- no connection can be initiated to the desktop computer
- connections to the HTTP and SSH service to the server are allowed
From inside the bridge, the desktop computer and the web server can initiatiate connections to anywhere:
% nft add table bridge filter
% nft add chain bridge filter forward '{type filter hook forward priority 0; }'
% nft add rule bridge filter forward ct state established,related accept
% nft add rule bridge filter forward iif { eth0, eth1 } oif eth2 ct state new accept
% nft add rule bridge filter forward iif eth2 oif eth1 ct state new tcp dport { 22, 80, 443 } accept
Source : Bridge filtering (wiki.nftables.org) (https://wiki.nftables.org/wiki-nftables/index.php/Bridge_filtering#Example:_Stateful_bridge_firewall)
Faut-il créer un premier pont avec les ports eth0, eth1 ?
Faut-il ensuite former un second pont reliant le premier pont « lan » (eth0, eth1) au port uplink « wan » eth2 ?
-
Il me semble que cela ne pourra pas fonctionner.
Après moult recherches et questions posées, j'en suis arrivé à penser que le commutateur matériel embarqué dans mon routeur réalise par lui-même la commutation.
MT7530 is a 7-ports Gigabit Ethernet Switch that could be found on Mediatek router platforms such as MT7623A or MT7623N which includes 7-port
Gigabit Ethernet MAC and 5-port Gigabit Ethernet PHY. Among these ports, the port from 0 to 4 are the user ports connecting with the remote devices
while the port 5 and 6 are the CPU ports connecting into Mediatek Ethernet GMAC.
The patch series integrated Mediatek MT7530 into DSA support which includes the most of the essential callbacks such as tag insertion for
port distinguishing, port control, bridge offloading, STP setup and ethtool operations to allow DSA to model each user port into independently
standalone netdevice as the other DSA driver had done.
Source : https://lwn.net/Articles/719278/
RTL8367, 88E6393X, 88E6191X, 88E6190, MT7621 and MT7531 switch chips can use HW offloaded vlan-filtering since RouterOS v7.
Source : https://help.mikrotik.com/docs/display/ROS/Basic+VLAN+switching
Add new support for MT7531:
MT7531 is the next generation of MT7530. It is also a 7-ports switch with 5 giga embedded phys, 2 cpu ports, and the same MAC logic of MT7530. Cpu
port 6 only supports HSGMII interface. Cpu port 5 supports either RGMII or HSGMII in different HW sku. Due to HSGMII interface support, pll, and
pad setting are different from MT7530. This patch adds different initial setting of MT7531.
Source : https://lkml.iu.edu/hypermail/linux/kernel/1912.1/01770.html
-
J'ai aussi trouvé une réponse à une question posée dont je n'arrivais pas à comprendre le sens.
You should get a device that has two “true” Ethernet interfaces. Some super cheap routers actually only have one Ethernet interface and use port-based VLANs on the built-in switch to split this one interface into multiple.
This will severely limit achievable throughput/bandwidth. Chances are you wouldn’t be able to use these anyway (no OpenWrt support).
[...]
You must make sure the device is connected to your existing network such that no traffic can bypass its CPU. On a typical router, you’d just connect the WAN port to the uplink router (your existing modem/router device)
and everything else to the LAN side.
[...]
Hardware offloading interferes with filters, because the switch chip deals with traffic internally. It should however not apply to bridges between physical interfaces on the CPU/SoC.
Bridge Fast forward may interfere with filters, too, and may have to be disabled.
Source : Daniel B. (Can OpenWRT serve with a switch and do IP filters and how? -- SuperUser.com (https://superuser.com/questions/1764740/can-openwrt-serve-with-a-switch-and-do-ip-filters-and-how))
Je crois que créer un pont entre les interfaces physiques eth1 et eth0 (interface maître) incorporées dans le routeur ne fonctionnera pas davantage.
Common pitfalls using DSA setups
Once a master network device is configured to use DSA (dev->dsa_ptr becomes non-NULL), and the switch behind it expects a tagging protocol, this network interface can only exclusively be used as a conduit interface. Sending packets directly through this interface (e.g.: opening a socket using this interface) will not make us go through the switch tagging protocol transmit function, so the Ethernet switch on the other end, expecting a tag will typically drop this frame.
Source : Linux Kernel Documentation : The DSA Architecture. (https://www.kernel.org/doc/html/v5.9/networking/dsa/dsa.html#common-pitfalls-using-dsa-setups)
-
Mais je n'en suis pas certain car il y a trop de choses que je ne sais pas.
Exemple :
Le déchargement matériel (hardware offload) est-il activé de façon systématique et permanente ?
Quel type de déchargement matériel peut-être pris en charge par nftables ?
Lien
Netfilter's flowtable infrastructure (https://www.kernel.org/doc/html/latest/networking/nf_flowtable.html)
[BPI-R3] hardware offloading with flowtables (https://forum.banana-pi.org/t/bpi-r3-hardware-offloading-with-flowtables/15835)
-
En résumé
Avec le noyau Linux, on peut établir un pont logiciel entre des interfaces physiques et esclaves. En effet, cela est effectué dans la configuration OpenWrt par défaut du BPI R3.
Donc, en pratique, je pense pouvoir créer un pont entre eth1 (port SFP « montant ») et lan1 (port du commutateur).
Niveau sécurité
Le plus simple est d'installer un équipement transparent sur le réseau (mode pont) et stocker les captures réseaux dans une unité de stockage du commutateur. Puis finalement
de débrancher l'équipement afin de pouvoir exploiter les données. Techniquement, l'équipement se situe dans un segment du réseau Orange. Mais logiquement, comme le
boîtier Internet, il se trouve chez l'abonné.
-
Mais ce n'est pas le plus pratique et le plus facile à réaliser.
On peut créer plusieurs ponts isolés sur un commutateur avec le système DSA. (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial#multiple_bridged_networks)
Topologie envisagée (DSA)
Pont entre eth1 et wan. Ce sera la liaison entre le réseau Orange et la Livebox.
Pont n'ayant qu'un seul port e.g. lan1. Interface IP locale au lien vers le routeur en mode pont.
Note : wan est un port du commutateur.
De cette manière, on peut lancer manuellement une capture tcpdump locale sur le routeur en mode pont, de sa station (à distance).
-
Le GS108Tv3 permet déjà de faire du port mirroring (page 428 à 430 du manuel) :
https://www.modesdemploi.fr/netgear/gs108tv3/mode-d-emploi?p=428
Extrait traduit :
Configurer la mise en miroir des ports
La mise en miroir des ports vous permet de sélectionner le trafic réseau de ports de commutation spécifiques pour analyse par un analyseur de réseau. Vous pouvez sélectionner de nombreux ports de commutation comme ports sources, mais un seul port de commutation comme port de destination. Vous pouvez configurer la manière dont le trafic est mis en miroir sur un port source en sélectionnant les paquets reçus, transmis ou les deux.
Un paquet copié sur le port de destination est au même format que le paquet d'origine sur le câble. Cela signifie que si le miroir copie un paquet reçu, le paquet copié est étiqueté VLAN ou non étiqueté comme il a été reçu sur le port source. Si le miroir copie un paquet transmis, le paquet copié est étiqueté VLAN ou non étiqueté comme il est transmis sur le port source.
Pour activer globalement la mise en miroir des ports, spécifiez le port de destination et spécifiez un ou plusieurs ports sources :
1. Connectez votre ordinateur au même réseau que le commutateur. Vous pouvez utiliser une connexion Wi-Fi ou filaire pour connecter votre ordinateur au réseau, ou vous connecter directement à un commutateur hors réseau à l'aide d'un câble Ethernet.
2. Lancez un navigateur Web.
3. Dans le champ d'adresse de votre navigateur Web, saisissez l'adresse IP du commutateur.
Se lancer dans la conversion d'un routeur en Switch non manageable par souhait de le rendre injoignable de l'extérieur pour éviter une attaque dessus est complètement absurde, à quel moment il serait joignable de l'extérieur dans cette configuration :
Arrivé Fibre <-> SFP <-> GS108Tv3 <-> LiveBox
|
|⟶ Station
Dans cette configuration ton GS108Tv3 est complètement transparent et ta station connectée dessus n'est en rien connectée à internet, ce qui est connecté à internet c'est tout ce qui est derrière la LiveBox, là ton GS108Tv3 est en amont de celle-ci et opère comme un Switch et encore, je pense même pas qu'on puisse appeler ça Switch dans cette configuration puisqu'on crée une connexion de pont entre 2 ports physiques pour relier 2 appareils avec un miroir de cette connexion de pont pour capturer le trafic.
-
@xp25 :
Mon commutateur GS108Tv3 n'a pas de cage SFP. On ne peut pas le brancher à la prise optique murale sans adaptateur.
De plus, je dispose déjà du matériel (BPI R3 + ONU) et des ressources logicielles (OpenWrt), ainsi que les connaissances
nécessaires pour le faire (j'ai passé un temps énorme dessus à travers des livres, des documentations, recherches Web).
Cela pourrait se mettre en place en un temps éclair une fois que l'on saisit bien ce que l'on fait. Si je convertis le routeur
en commutateur c'est par efficacité et coût. Je n'ai jamais prévu d'investir dans un commutateur uniquement pour pouvoir
le brancher sur la prise optique du réseau Orange. Je voulais un commutateur avec des fonctionnalités IPv6 et VLAN pour
segmenter mon réseau local et ajouter de nouveaux ports RJ45. Disposer de cela avec un port SFP aurait grandement
augmenté le prix d'achat. D'autant plus que c'est le routeur de substitution (BPI R3) qui est censé être branché sur la
prise optique du réseau Orange.
Le but de la manœuvre est de créer un pont transparent par sécurité et simplicité au niveau de la topologie. Je n'aurai
pas de pont filtrant (ou transparent) (https://www.fortinet.com/fr/resources/cyberglossary/transparent-firewall) mais deux ponts isolés. Le second pont offrant un accès local (résidentiel) au routeur
ayant le rôle de pont.
-
La Livebox envoie des paquets DHCPv4 Discover et DHCPv6 Solicit. Je les capture avec tcpdump (je suis connecté à mon routeur) sur l'interface reliée au module optique.
Malheureusement, aucune réponse du réseau Orange. Mon module optique est le GPON de fs.com. L'état de l'ONU est O5. Mon routeur est le BPI R3. Et d'autres gens ont
réussi à avoir une connexion Orange en utilisant le même module sur ce routeur.
Je n'ai aucune idée de là où pourrait se situer le problème. Il me semble que ce n'est pas un problème de configuration... puisque c'est la Livebox qui réalise la connexion.
-
Enfin, il y aurait peut-être ce problème de récupération de la sauvegarde de la configuration ?
Parce que lors d'une seconde capture, après extinction de la Livebox, je ne n'apercevais plus les paquets du NDP et requêtes ARP.
Autre chose étonnante, dans les paquets DHCPv6 Solicit, je n'aperçois pas les valeurs de certaines options avec tcpdump -evni eth1.
Re : il faut que j'essaye à nouveau !!
-
Je suis parvenu à faire fonctionner ce pont. Normalement, capturer le trafic ne devrait être plus qu'une formalité. Il faudrait néanmoins que je filtre sur le second pont.
Mon module optique n'était pas totalement configuré. J'ai aussi assigné la même MAC à des interfaces différentes. Le pare-feu fw4 était activé pour protéger le second pont
et la zone wan était configurée pour tout bloquer (mais normalement cela ne devrait pas avoir d'influence puisque les transmissions sont réalisées sur la couche liaison).