securisé son " routeur perso "

iznobe · Le 15/02/2021, à 17:06

Bonjour a tous ,

Depuis chez moi j ' utilise mon telephone pour me connecter a internet par l' intermediare d ' un " routeur maison " , je n' ais pas vraiment le choix en meme temps , c 'est soit la 4G soit le satellite .

pour cela j' ai donc acheter un raspberry pi et je connecte mon tel sur le port usb en partage de connexion lorsque la petite famille en a besoin .

j ' aurais voulu donc securiser un peu mieux tout cela , car pour le moment tout est grand ouvert .
Alors c ' est pas la NASA chez moi , mais bon , j ' aimerais eviter les intrusions quand meme
ca permet aussi d ' economiser de la bande passante aussi au cas ou un malin aurait l' idée d ' utilise ca pour relayer .

l ' OS installé est raspbian buster ou raspiOS maintenant je crois .
mon pi fait donc office de passerelle , de pont , de serveur DHCP .

Apres 2 mois lire des tutos des docs un peu partout je n' arrive pas a faire marcher iptables aux petits oignons , mais je pense pas etre loin de quelquechose de pas trop mal .

voici donc la carte des interfaces actuelles :

pi@rasphomefi:~ $ ifconfig -a
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.1  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::e169:a2a1:b2d6:55c9  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:8f:c7:b4  txqueuelen 1000  (Ethernet)
        RX packets 69865  bytes 12040893 (11.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 87665  bytes 75462088 (71.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::ba27:ebff:feda:92e1  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:da:92:e1  txqueuelen 1000  (Ethernet)
        RX packets 27326  bytes 3587039 (3.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 31875  bytes 27476005 (26.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Boucle locale)
        RX packets 88  bytes 5943 (5.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 88  bytes 5943 (5.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.42.87  netmask 255.255.255.0  broadcast 192.168.42.255
        inet6 fe80::2010:28ff:feb8:4390  prefixlen 64  scopeid 0x20<link>
        inet6 fe80::5c99:eaa5:e1f5:cc2  prefixlen 64  scopeid 0x20<link>
        inet6 2a02:8440:5101:d196:2724:eefc:e4db:3460  prefixlen 64  scopeid 0x0<global>
        inet6 2a02:8440:5101:d196:2010:28ff:feb8:4390  prefixlen 64  scopeid 0x0<global>
        ether 22:10:28:b8:43:90  txqueuelen 1000  (Ethernet)
        RX packets 86029  bytes 74123354 (70.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 63170  bytes 14501673 (13.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::ba27:ebff:fe8f:c7b4  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:8f:c7:b4  txqueuelen 1000  (Ethernet)
        RX packets 42868  bytes 8528451 (8.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 61200  bytes 50961911 (48.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@rasphomefi:~ $

et la sortie des tables filter et nat d ' iptables :

pi@rasphomefi:~ $ sudo iptables -t nat -L -v -n --line-numbers
Chain PREROUTING (policy ACCEPT 5033 packets, 1120K bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 1203 packets, 94402 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 38 packets, 4714 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     1544  246K MASQUERADE  all  --  *      usb0    0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 474 packets, 35585 bytes)
num   pkts bytes target     prot opt in     out     source               destination
pi@rasphomefi:~ $ sudo iptables -t filter -L -v -n --line-numbers
Chain INPUT (policy ACCEPT 70 packets, 10918 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       88  5943 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
2      430 58223 ACCEPT     all  --  usb0   *       0.0.0.0/0            192.168.42.0/24      state RELATED,ESTABLISHED
3     3876  382K ACCEPT     all  --  br0    *       192.168.1.0/24       0.0.0.0/0

Chain FORWARD (policy ACCEPT 45 packets, 3278 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1    62394   11M ACCEPT     all  --  br0    usb0    192.168.1.0/24       0.0.0.0/0            state NEW,RELATED,ESTABLISHED
2    85409   74M ACCEPT     all  --  usb0   br0     0.0.0.0/0            192.168.1.0/24       state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 44 packets, 4554 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     2230  209K ACCEPT     all  --  *      br0     192.168.1.0/24       192.168.1.0/24
2       88  5943 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
3      503 38831 ACCEPT     all  --  *      usb0    192.168.42.0/24      0.0.0.0/0            state NEW,RELATED,ESTABLISHED
pi@rasphomefi:~ $

j ' ai evidemment fait plein d' autres essais avant de venir poster , je me suis aussi retrouver avec juste la resolution des noms qui ne marchait plus une fois.
une autre fois , c ' etait le wifi qui ne se connectait plus .

il s ' avere que lorsque je met INPUT FORWARD et OUTPUT en regle par defaut a DROP , j ' ai un soucis , le serveur DHCP ne parait plus fonctionnel .
Par contre en IP fixe ca a l' air de marcher .

D ' apres mes tests , il semblerait que le probleme se situe dans la table filter chaine input .

Bref , il me manque certainement juste un petit coup de pouce pour que cela fonctionne au top .

Si quelqu ' un pourrait m' aiguiller vers la solution du probleme actuel ca serait genial !

Dernière modification par iznobe (Le 15/02/2021, à 17:44)

Zakhar · Le 15/02/2021, à 18:58

Il manque des infos...

Ton "routeur" permet l'accès à internet aux autres postes connectés à quoi ?

Ethernet,
Wifi,
Les deux mon capitaine ?

A quoi sert ton Bridge ?

En pratique une connexion mobile est de toute façon un "faux" accès internet. Tu ne peux pas héberger un serveur web sur ton smartphone !..
Donc du moment que ton DHCP marche, tu n'as pas besoin de t'amuser à filtrer ce qui rentre, puisque c'est l'ensemble vide.

(Sauf peut-être en ipv6... à vérifier la politique des opérateurs sur ça... mais là tu n'as pas ou ne montres pas de règles ipv6)

iznobe · Le 15/02/2021, à 19:31

Salut Zhakar et merci de t' interresser a mon probleme .

Je pensais que le ifconfig eclaircirait les choses .

oui grace a mon routeur perso , ma petite famille peut aller sur internet avec mon ordi , celui de ma femme , celui de ma fille tablette de ma fille et de mon petit gars
Occasionellement les telephones de tout ce petit monde se connecte aussi en wifi quand leur forfait data est epuisé .

Alors le routeur sert a passer l' internet du telephone en partage de connexion par USB sur le reseau local , lequel est constituté donc du wifi et de l' ethernet ponté ensemble .
le port ethernet est relié a un switch qui distribue dans la maison .
l ' ethernet et le wifi n' ont pas d' adresse IP seul le telephone et le pont en ont une .
le routeur est aussi passerelle du reseau local donc et a pour IP : 192.168.1.1 .

je ne veux rien hebergé du tout chez moi , juste acceder a internet a partir du LAN quand besoin , je n ' ai pas d' autres choix , pas de ligne telephonique chez moi , par contre la 4G passe pas trop mal .

Apres je ne m ' y entends pas assez pour savoir si un intrus peut tenter des choses , mais je ne vois pas pourquoi il ne pourrait pas faire comme sur un acces internet standard .
Si vous avez un lien expliquant cela je suis preneur , j ' aurais apris quelquechose au moins et vous en remercie .
ca semble trop beau pour etre vrai cette histoire , un acces internet inpenetrable ???

Je n' ai pas mis de regle ipv6 car pour le moment je ne me suis pas encore interressé a cela .

Dernière modification par iznobe (Le 15/02/2021, à 20:11)

Zakhar · Le 15/02/2021, à 20:42

C'est simple, il n'y a juste pas assez d'ipv4 pour tout le monde.

Donc, ça dépend des opérateurs, mais dans la plupart des cas l'opérateur va te donner une IP "NATéé" qui te permet de sortir depuis ton smartphone vers le web, mais pas l'inverse.
Et ça tombe bien les usages du gogo commun sur smartphone, c'est juste de "sortir" vers le web, pas d'héberger un site web pour le public !..
A peu près exactement comme une box.
La différence d'une box c'est que tu peux en général paramétrer des redirections de port pour atteindre tes machines locales depuis l'extérieur, là pas du tout car il faudrait accès à l'infrastructure de ton opérateur lequel t'attribue aléatoirement une IP au moment où tu te connectes !

Même si jamais tu avais une ipv4 routable, au pire un "adversaire" pourrait venir sur ton smartphone, mais n'irait pas au delà vu que la connexion vers ton Pi est un autre sous-réseau (192.168.xx.xx) qui est du "local non routable".
Ou alors ça supposerait que l'adversaire a tellement pwné ton smartphone qu'il a réussi a être root et à mettre des bonnes règles de routage pour atteindre tout ce qui est derrière, puis pwne successivement ton Pi et tout le reste.

Bref, c'est le sketch de la chauve-souris de Bigard à ce niveau là !..

Mais bon ça c'est pour l'ipV4 et la NAT qui fait une "protection naturelle" en quelque sorte, malgré ses inconvénients.

Pour l'ipV6 il en va tout autrement, puisque c'est précisément fait pour que tout appareil soit adressable.

Dernière modification par Zakhar (Le 15/02/2021, à 20:44)

iznobe · Le 15/02/2021, à 20:57

Merci pour ces infos ,

J ' irai donc voir de plus pres ce qu ' il en est pour ces IPv4 " NATée ".

Pour aller plus loin si j' ai bien compris , il faudrait savoir comment mon FAI " fabrique " ses connexions ? si mon smartphone est en l ' IPv6 il se peut qu ' il y a ait des problemes de securité , mais si c ' est de l ' IPv4 , impossible ?

Parfois je laisse mon smartphone connecté au pi la nuit , et il ne quitte que tres rarement la connection 4G , il est connecté presque tout le temps , c surtout ca qui me fait un peu peur .

Pour en savoir plus qu sujet de l' ipv4 / 6 et savoir si vous etes connecté en IPV4 ou en IPV6 voici un lien qui peut etre interessant :
https://www.arcep.fr/la-regulation/gran … -ipv4.html

Dernière modification par iznobe (Le 15/02/2021, à 21:05)

iznobe · Le 15/02/2021, à 21:15

que pensez de ce ce petit message :

Les pare-feu (Firewall) ont pour objectif de filtrer les communications TCP/IP. Ils sont capables de tenir compte des sessions établies à partir d’une zone de confiance et d’empêcher tout trafic initié de l’Internet.
Quand ils sont placés dans le réseau (ailleurs que sur les hôtes), ils remplissent des tâches de routage. La plupart du temps cette fonction “pare-feu” est intégrée aux routeurs.
On a tendance à confondre les fonctionnalités NAT avec celles du pare-feu.
Même s’il est probable que le même logiciel prenne en charge les deux fonctions, ces procédures sont distinctes. Alors que le NAT sert à traduire le trafic, il ne protège en rien.
Cette fonction de filtrage est prise en charge par le pare-feu à état qui arrête les connexions non sollicitées sur le réseau à protéger. Quant à lui, le proxy offrira d’autres fonctions que la traduction telle que le contrôle du trafic, des mécanismes de cache, avec ou sans authentification, …
Dans tous les cas, c’est la fonction pare-feu qui protège des tentatives de connexions externes

situé dans le paragraphe 13 de cette page :
https://cisco.goffinet.org/ccna/ipv4/in … resses-ip/

Zakhar · Le 15/02/2021, à 21:23

En ipv6, voici la protection minimale que j'utilise, inspirée de ça :

https://gist.github.com/velizarn/9c5bd1 … 65d400f522

ip6tables -A INPUT -i enp0s31f6 -s fe80::/64 -j ACCEPT
ip6tables -A INPUT -i enp0s31f6 -s 2a01:1111:2222:3333::/64 -j ACCEPT # Accept my Freebox
ip6tables -A INPUT -i enp0s31f6 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -i enp0s31f6 -m limit --limit 2/min -j LOG --log-prefix "IP6Tables-Input-Dropped: " --log-level 4
ip6tables -A INPUT -i enp0s31f6 -j REJECT --reject-with icmp6-adm-prohibited

-1) Accepte tout ce qui est sur le "link local" (le fil ethernet)
-2) Accepte tout ce qui provient de mon réseau local ipv6 (adresse modifiée, regarder par exemple chez Free, dans l'interface Freebox, quelle est votre ipv6 publique)
-3) Accepte les réponses aux connexions qu'on a soi-même initiées
-4) Journalise le reste (les espions !)
-5) Puis rejette le reste

Exemple de log au démarrage :

grep 'IP6Tables-Input-Dropped' /var/log/syslog 
Feb 15 21:07:58 alain-HTPC kernel: [  479.810548] IP6Tables-Input-Dropped: IN=enp0s31f6 OUT= MAC=11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee SRC=2600:9000:20e1:6e00:000a:da5e:7900:93a1 DST=2a01:1111:2222:3333:4444:5555:6666:7777 LEN=60 TC=0 HOPLIMIT=53 FLOWLBL=335115 PROTO=TCP SPT=443 DPT=52714 WINDOW=0 RES=0x00 RST URGP=0

Quand on regarde la correspondance de cette ipv6 : 2600:9000:20e1:6e00:000a:da5e:7900:93a1

Owner: AMAZON-02, US

(Source : https://www.ultratools.com/tools/ipv6In … 900%3A93a1 )

Zakhar · Le 15/02/2021, à 21:35

iznobe a écrit :

que pensez de ce ce petit message :
Même s’il est probable que le même logiciel prenne en charge les deux fonctions, ces procédures sont distinctes. Alors que le NAT sert à traduire le trafic, il ne protège en rien.

Quand on ne comprend pas les réseaux... on croit ce qui est écrit !

Rassure-toi, les connaissances générales en informatique sont déjà assez nulles, en réseau il faudrait inventer des notes négatives !...

La phrase est totalement trompeuse.

Bien sûr que la NAT ne protège aucun trafic sortant, ce n'est pas son rôle !..
Mais par contre elle est une excellente protection -indirecte- contre tout trafic entrant, même si ce n'est pas son rôle fondamental, c'est une conséquence de son fonctionnement.
Et il me semble que c'est ce que tu cherches non ?

Imagine la chose suivante.

Tu es une entreprise, et pour ne pas dépenser trop d'argent en téléphone, tu as un "standard" joignable avec un seul numéro : 01 40 41 42 43 44 (en réseau ton ipv4 publique unique)
Derrière ce standard, il y plusieurs postes de téléphone, qui ont des "numéros internes" (en réseau, des adresses "de réseau local")

En général ce qu'il se passe dans ce cas là, c'est que les gens utilisant leur "poste interne" peuvent :
- se téléphoner entre eux (en interne = "réseau local")
- appeler l'extérieur. Lorsqu'ils appellent un interlocuteur externe, celui-ci peut bien sûr à la fois entendre ce qu'il se dit et répondre.

Par contre, personne ne peut joindre directement les postes internes depuis l'extérieur, il faut passer par le standard au 01 40 41 42 43 44 et demander d'être connecté au poste 591 pour avoir l'interlocuteur au poste 591.

Eh bien voila, la NAT c'est exactement ça.
Passant dans un sens : interne vers externe
Bloquant dans l'autre : externe vers interne.

Alors ce que tu peux faire quand tu as la main sur la NAT (ta Freebox), c'est dire : tous ceux qui appellent le "service compatibilité", il faut les connecter au poste interne 591. Cela permet aux interlocuteurs cherchant à joindre ce service de "sauter" le standard et être connecté direct.

En IP c'est la "redirection de port". Tu vas dire à ta box, celui qui cherche à joindre le port 443 (https) il doit aller sur 192.168.0.200 (là où tu as mis ton Pi qui expose du https).

Donc oui, il te faut encore un peu de lecture sur les réseaux.

Et comme dit plus haut, l'IPV6 étant "globalement adressable" n'a pas cette "protection naturelle" de la NAT.
En fait si un adversaire attaque ton ipv4, en ADSL/fibre, c'est ta box qu'il va attaquer, pas les PC qui lui sont connectés. Et heureusement la plupart des box "sérieuses" te protègent correctement.
(Sauf si tu n'as qu'un seul PC et que tu as explicitement mis ta box en mode "non-routeur", ce qui est possible avec la Freebox... et que je ne recommande pas sauf usage particulier du gars qui maîtrise ce qu'il fait !)

De même dans ta config, si un adversaire attaque ton ipv4 publique, il va attaquer :
- Soit ton fournisseur si celui-ci te donne une IP "NATée"
- Soit ton smartphone si l'ipv4 est routable (l'ipv6 est par défaut routable)

Et donc avant d'attaquer le reste, il faut déjà pwner soit ton fournisseur, soit ton smartphone.
De là il faut "rebondir" sur chaque segment de réseau et pwner les machines qui font office de routeur à chaque fois, donc ton smartphone (routage 4G-ethernet/USB) et ton Pi (routage Ethernet/USB - le reste de ton réseau).

Bref, c'est pas gagné pour entrer comme ça.
L'entrée classique des "méchants" se fait donc à l'envers. Comme la bêtise humaine est largement plus infinie que celle de l'univers (dixit Einstein), c'est en général l'utilisateur qui peut toujours faire de trafic "sortant" qui invite un joli cheval de troie lequel se trouvant maintenant "à l'intérieur" peut alors faire ce qu'il lui chante.

Mais le filtre iptable qui protège de l'ensemble de la bêtise humaine n'a hélas pas encore été inventé, donc là mon seul conseil c'est la vigilance et les bonnes pratiques -comme les "gestes barrière"- !

Dernière modification par Zakhar (Le 15/02/2021, à 21:56)

iznobe · Le 16/02/2021, à 14:28

Salut ,
ok merci pour toutes ces explications !
avant de me lancer dans l' IPV6 directement j ' aurais aimer finaliser le tir avec les regles IPV4 dejà , comme je suis debutant dans le domaine , je prefere y aller lentement mais surement

Avec les regles que j' ai mis dans iptables je pensais n' avoir rien oublié et que ca marcherait cependant ce n' est a priori pas le cas , savez vous pourquoi le probleme de DHCP qui ne fonctionne pas ?

je pensais que la regle 1 et 3 de INPUT faisait que mon reseau local etait entièrement libre d' aller sur le pi vial ' interface br0 , ce n' est pas le cas ?

lorsque ca sera 100 % fonctionnel en IPV4 , je pense qu ' il suffira juste de traduire les masque reseaux , les reseaux et les ip en version 6 non ?

Et si j' ai bien suivi et apres maintes lectures sur l' adressage IPV4 / IPV6 , la version 4 est amenée a disparaitre et c ' est pour bientot .
Donc dans quelques temps mon IP a partir de la 4G sera exposée pleinement , alors autant me pencher sur la question des maintenant car c ' est pour tres bientot si j' ai bien compris , meme si il n ' y a pas encore de date definit .

De plus mon abo data est chez RED ( SFR ) et lorsque je suis connecté , il m' affiche les 2 types d' adresses , donc selon ce qu ils ont de dispo chez SFR , je pense qu ' il balancent soit du v4 soit du v6 et ca doit changer meme pendant l ' utilisation dynamiquement car parfois j ' ai des coupures de debit plus moins longues ...

De toute manieres je n ' aurai pas le choix de le faire un jour .

si on trouve ce qui ne vas pas actuellement en IPV4 , une fois corrigé , je m' attelerai a passer les regles en IPV6 , ca parait plus simple pour un novice comme moi

j ' ai remarqué que dans vos regles ipv6 vous utilisez le module contrack pour effectuez le suivi de connection , c ' est parceque le module mstate n ' est pas compatible ipv6 ?

Dernière modification par iznobe (Le 16/02/2021, à 15:19)

iznobe · Le 16/02/2021, à 20:50

Re ,
finalement j' ai fini par trouver la regle a inplanter dans la table filter chain INPUT , mais pas facile pour mettre la main dessus ...
meme avec des recherches pour connaitre le fonctionnement du serveur DHCP , il y en a tres peu qui precise qu ' il envoie des paquets UDP sur les ports 67 et 68 , par contre le DHCPOFFER et tout le touin touin , ca tu le connais par coeur apres

donc pour ceux que ca interresse , la regle a ajouter pour que le serveur DHCP IPV4 fasse son boulot c ' est :

sudo iptables -t  filter -A INPUT -p udp -i $int --dport 67:68 -j ACCEPT

en emplacant $int par le nom de votre interface .

Voilà il me reste plus qu ' a passer tout ca en IPV6 ...

comment on specifie un reseau en IPV6 ?
quelle adresse correspond a 192.168.1.1 ? y a un traducteur d' adresse qui existe quelquepart ?

Dernière modification par iznobe (Le 16/02/2021, à 20:53)

Zakhar · Le 16/02/2021, à 21:43

Quelques conseils :

- Tu n'a pas besoin du bridge pour juste aller sur internet depuis les PC/devices connectés en Wifi/Ethernet, ça complexifie pour rien, plus tu pollues les deux réseaux avec les broadcasts qui doivent être répétés d'un à l'autre
- Les règles iptables ne font pas tout !
- Il te faut surtout et essentiellement activer le "forward" dans le kernel, la seule règle iptables nécessaire est la "masquerade" (la NAT !) [Hormis d'éventuels filtrages sortants, car en ipv4, pour l'entrant c'est à peu près inutile vu que ton smartphone (au moins) fera barrage... après tu peux aussi mettre un deuxième barrage... c'est toi qui vois, mais fais d'abord marcher la base sans complexifier !]
- pour le DHCP, il faut effectivement un serveur DHCP sur ton PI. Jamais exploré la chose, mais j'utilisais le micro serveur dnsmasq à une époque (il est partiellement en dépendance de NetworkManager sur Ubuntu). Il est bien possible que "Systemd-qui-fait-tout" sache également faire serveur DHCP. Lis les docs à ce sujet.
- Tu vas avoir aussi la question de présenter à tes "clients DHCP" un DNS convenable... à toi de voir ce que tu peux utiliser !
- La règle d'input de ton post précédent ne sert qu'à ton raspberry Pi à récupérer une IP sur la liaision avec le smartphone via le serveur DHCP de celui-ci pour la fonction tethering. C'est pourquoi je t'ai conseillé de ne PAS filtrer l'input dans un premier temps : ça ne sert à rien, et ne te crée que des blocages. Ce n'est à faire que si vraiment tu veux des règles "parano" (et tu pourras vérifier qu'elles ne sont jamais utilisées en faisant de temps en temps un iptables -L !), et seulement une fois que tout le reste marchera.

Si tu as des docs à lire, c'est plutôt comment on fait un "routeur" sur une machine Linux.

iznobe a écrit :

j ' ai remarqué que dans vos regles ipv6 vous utilisez le module contrack pour effectuez le suivi de connection , c ' est parceque le module mstate n ' est pas compatible ipv6 ?

La seule raison est que je me suis inspiré du lien donné plus haut, et que ça fonctionne bien ainsi.
Je te laisse essayer avec mstate, c'est peut-être également Ok...

Au fait j'en ai profité pour affiner et rajouter une règle évitant de journaliser les paquets invalides, donc avant la règle de "log" :

ip6tables -A INPUT -i enp0s31f6 -m state --state INVALID -j DROP

(Les paquets journalisés provenant d'Amazon dans mes posts précédents, sont des "invalides", sans doute un RST sur une connexion déjà fermée)

Dernière modification par Zakhar (Le 16/02/2021, à 22:00)

iznobe · Le 17/02/2021, à 07:55

Salut Zahkar ,

tout le reste marche justement parfaitement bien , ca fait plus d' un an que je teste cette config , elle n' est pas de moi bien sur ,c ' est @epoch1970 du forum raspberry pi qui m ' a donné la soltuion .
le pont sert a se retrouver avec le même reseau local pour le wifi et l' ethernet local , du genre si je veux aller sur mon pi ou sur un ordi avec mon telephone sur ur ordi du reseau .

bref , tout est vraiment impeccable , il ne manque que la configuration d ' iptables afin de protege un minimum tout ca .
je viens de faire une partie du travail , celle en ipv4 il reste a traduire en ipv6 et la config serait vraiment terminé .

Dernière modification par iznobe (Le 17/02/2021, à 12:36)

iznobe · Le 17/02/2021, à 12:49

Bonjour , j ' aurais encore quelques questions avant de me lancer dans l' adressage ipv6 ,

Dans le reseau local , lors du passage a l ' ipv6 , il faut aussi écrire les adresse au format inet6 ?
on ne pourra plus utiliser la notation decimale ?

c' est pas dit clairement dans tout ce que j' ai pu lire ...

est ce qu ' il ya quelquechose a faire pour la reegle de NAT ( masquerade ) ipv6 ?

et qu ' en ert il des POLICY par defaut ( en ipv6 ) ?

Dernière modification par iznobe (Le 17/02/2021, à 13:29)

Zakhar · Le 17/02/2021, à 15:55

iznobe a écrit :

Salut Zahkar ,
le pont sert a se retrouver avec le même reseau local pour le wifi et l' ethernet local , du genre si je veux aller sur mon pi ou sur un ordi avec mon telephone sur ur ordi du reseau .

Oui, c'est pourquoi je disais : le pont ne sert à rien, si c'est pour l'accès internet. Bien sûr si tu veux pouvoir parler entre n'importe quelle machine en Wifi et n'importe quelle machine en Ethernet, faire un "pont" est bien plus simple que du routage... mais présente les inconvénients listés plus haut : broadcast, complexité.

Donc c'est selon tes besoins effectivement.

L'IPV6 s'écrit en 8 blocs de 4 caractères hexa séparés par des ":"

2a01:ecf1:0789:bd17::1456:123

La notation "::" condense les zones "vides", c'est à dire quand tu as des 0000.

Plus ou moins, l'ipv6 ça s'auto-configure tout seul grâce à SLAAC, et il n'y a pas de notion quasi obligatoire de NAT puisqu'il a assez d'adresses ipV6 pour tout le monde et tous leurs gadgets pour que les ipv6 de classe globale soient "routables".
Et comme précisément il n'y a pas de NAT (par défaut)... eh bien tu n'es plus protégé du "trafic entrant" précisément par le routeur qui fait office de NAT !..

Il y a quelques particularités comme éviter de bloquer le "ping6" car il sert à pas mal de chose en ipv6 (dont SLAAC)

Sinon, comme tu le vois ci-dessus, iptables fonctionne tout pareil en ipv6, tu mets juste ip6tables à la place de iptables, et bien sûr des adresses V6 !..
Il y quelques mots clé nouveaux sur les ICMP (ping) puisque précisément ils servent beaucoup.

Dernière modification par Zakhar (Le 17/02/2021, à 15:57)

iznobe · Le 17/02/2021, à 18:16

Coucou et merci pour ces explications

si vous le permettez du coup je vais posez ici les tables pour essayer de mettre les regles correspondantes en ipv6 et ajouter celles particulieres :

tables IPv4 :

pi@rasphomefi:~ $ sudo iptables -t filter -L -v -n --line-numbers
Chain INPUT (policy DROP 478 packets, 104K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     1989  164K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
2    11546 1903K ACCEPT     all  --  usb0   *       0.0.0.0/0            192.168.42.0/24      state RELATED,ESTABLISHED
3     356K   28M ACCEPT     all  --  br0    *       192.168.1.0/24       0.0.0.0/0
4       18  5994 ACCEPT     udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpts:67:68
5        0     0 ACCEPT     tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Chain FORWARD (policy DROP 2717 packets, 182K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1    1870K  188M ACCEPT     all  --  br0    usb0    192.168.1.0/24       0.0.0.0/0            state NEW,RELATED,ESTABLISHED
2    3456K 4027M ACCEPT     all  --  usb0   br0     0.0.0.0/0            192.168.1.0/24       state RELATED,ESTABLISHED

Chain OUTPUT (policy DROP 257 packets, 32427 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     489K  113M ACCEPT     all  --  *      br0     192.168.1.0/24       192.168.1.0/24
2     1989  164K ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
3    15602 1269K ACCEPT     all  --  *      usb0    192.168.42.0/24      0.0.0.0/0            state NEW,RELATED,ESTABLISHED
4       35  2688 ACCEPT     icmpv6    *      *       ::/0                 ::/0
pi@rasphomefi:~ $

tables IPv6 :

pi@rasphomefi:~ $ sudo ip6tables -t filter -L -v -n --line-numbers
Chain INPUT (policy ACCEPT 39990 packets, 31M bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all      lo     *       ::/0                 ::/0
2        0     0 ACCEPT     udp      br0    *       ::/0                 fe80::/64            udp dpt:546 state NEW
3       54  8572 ACCEPT     all      usb0   *       ::/0                 ::/0                 state RELATED,ESTABLISHED
4        6   488 ACCEPT     icmpv6    *      *       ::/0                 ::/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 31418 packets, 2673K bytes)
num   pkts bytes target     prot opt in     out     source               destination
pi@rasphomefi:~ $

Pour le moment je me concentre sur la table filter en INPUT , j ' ai 5 regles en INPUT IPv4 :
1)° pour la boucle locale .
2°) pour la connexion entrante du téléphone donc internet des connexions etablies auparavant par d ' autres regles.
3°) pour le reseau local
4°) pour le serveur DHCP
5°) pour le SSH

j ' ai donc essayé de faire la meme chose avec les regles IPv6 , logiquement vu qu ' il faut en ajouter une pour l ' ICMP je devrais en avoir 6 , sauf que je n' arrive pas a ecrire les 2 manquantes ...
1°) pour la boucle locale
2°) pour le serveur DHCP
3°) pour les connexions deja etablies par d' autres regles
4°) pour les ping IPv6

si je met par exemple :

sudo ip6tables -A INPUT -i br0 -j ACCEPT

c ' est suffisant ? je veux dire que comment je peux traduire la source ( provenance ) des IP " -s 192.168.1.0/24 " ?
et est ce que c' est necessaire pour plus tard , mon reseau local va passer aussi en IPv6 non ?

Peut etre en ajoutant " -s fe80::/64 " ?

j ' ai beau lire cette page : https://fr.wikipedia.org/wiki/Adresse_I … %C3%A9seau
a part chopper un mal de tete , pas grand chose qui rentre

Dernière modification par iznobe (Le 17/02/2021, à 19:03)

iznobe · Le 18/02/2021, à 08:05

Re bonjour,

A priori ca a l' air d' etre bon pour la regle et n ' utiliser que les IP d ' origine locale .
du coup il me manque plus qu ' une regle en input , celle pour le SSH dont je peux me passer vu que j ' y acced qu ' en local , si j ' ai bien suivi l ' idée generale et est autorisé par la regle 5.
voici ce que j' ai actuellement :

pi@rasphomefi:~ $ sudo ip6tables -t filter -L -v -n --line-numbers
Chain INPUT (policy ACCEPT 40084 packets, 31M bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all      lo     *       ::/0                 ::/0
2        0     0 ACCEPT     udp      br0    *       ::/0                 fe80::/64            udp dpt:546 state NEW
3     1835  314K ACCEPT     all      usb0   *       ::/0                 ::/0                 state RELATED,ESTABLISHED
4      982 77376 ACCEPT     icmpv6    *      *       ::/0                 ::/0
5      207 34054 ACCEPT     all      br0    *       fe80::/64            ::/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 36470 packets, 3185K bytes)
num   pkts bytes target     prot opt in     out     source               destination
pi@rasphomefi:~ $

Maintenant du coté input afin que ca filtre et eviter que les intrus detecte mon pi , je laisse la POLICY ipv6 en accept et pour derniere regle avec cette commande j ' ajoute une regle qui droppe tous les autres paquets sans rien renvoyer :

sudo ip6tables -A INPUT -j REJECT --reject-with icmp6-adm-prohibited

du coup je suppose qu ' en haut de la ligne " Chain INPUT (policy ACCEPT 40084 packets, 31M bytes) " je ne devrais plus avoir aucun paquet qui passe dedans et avoir zero paquets et zero bytes apres redemarrage .
ce qui donne :

pi@rasphomefi:~ $ sudo ip6tables -t filter -L -v -n --line-numbers
Chain INPUT (policy ACCEPT 40084 packets, 31M bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all      lo     *       ::/0                 ::/0
2        0     0 ACCEPT     udp      br0    *       ::/0                 fe80::/64            udp dpt:546 state NEW
3     1835  314K ACCEPT     all      usb0   *       ::/0                 ::/0                 state RELATED,ESTABLISHED
4      990 78064 ACCEPT     icmpv6    *      *       ::/0                 ::/0
5      207 34054 ACCEPT     all      br0    *       fe80::/64            ::/0
6        1    93 REJECT     all      *      *       ::/0                 ::/0                 reject-with icmp6-adm-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 36491 packets, 3187K bytes)
num   pkts bytes target     prot opt in     out     source               destination
pi@rasphomefi:~ $

Cela vous semble correct ?

Par ailleurs on peut voir que des paquets transite par l ' IPv6 , donc il est quand meme necessaire d ' etablir une protection non ?

Dernière modification par iznobe (Le 18/02/2021, à 08:22)

Zakhar · Le 18/02/2021, à 09:00

Rajoute la règle des invalides sur l'ipv6 (post #11), pas la peine de les rejeter (ça fait du trafic icmp6 en plus) il suffit de les "dropper" puisqu'ils sont invalides le système ne va rien en faire.

Pour juger de l'utilité de tes filtres, il faut faire une dernière règle qui journalise avant le DROP final. Ainsi tu verras si c'est utile ou pas, car je reste convaincu qu'en ipv4 ça ne l'est pas.
Pour l'ipv6 la protection est assez utile. On est relativement protégé par l'ignorance des gens dans ce protocole, et par le fait que c'est plus compliqué de trouver ton ipv6 surtout si tu as réglé le mode "privacy" qui changer l'ipv6 publique régulièrement. Mais parier sur l'ignorance globale n'est pas idéal, ceux qui pourraient faire des intrusions ont au contraire de bonnes connaissances !

Dernière modification par Zakhar (Le 18/02/2021, à 09:00)

iznobe · Le 18/02/2021, à 09:22

Merci pour vos conseils

ok j ' ai donc rajouté le DROP en INPUT pour tous les paquets inavlides ( je n' ai donc pas precisé d' interface , il me semble que c' est encore mieux ) .
j ' ai aussi rajouté les regles forward , mais honnetement je ne saurais dire si ce que j' ai fait a ce niveau là est bien ou pas ( 3 regles 2 filter et une postrouting )
et les regles de sorties similaires a celles d' IPv4 .
voilà le resultat :

pi@rasphomefi:~ $ sudo ip6tables -t filter -L -v -n --line-numbers
Chain INPUT (policy ACCEPT 40084 packets, 31M bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        7   969 ACCEPT     all      lo     *       ::/0                 ::/0
2        0     0 ACCEPT     udp      br0    *       ::/0                 fe80::/64            udp dpt:546 state NEW
3     1835  314K ACCEPT     all      usb0   *       ::/0                 ::/0                 state RELATED,ESTABLISHED
4     1020 80728 ACCEPT     icmpv6    *      *       ::/0                 ::/0
5      213 34848 ACCEPT     all      br0    *       fe80::/64            ::/0
6        0     0 DROP       all      *      *       ::/0                 ::/0                 state INVALID
7        0     0 REJECT     all      *      *       ::/0                 ::/0                 reject-with icmp6-adm-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all      br0    usb0    fe80::/64            ::/0                 state NEW,RELATED,ESTABLISHED
2        0     0 ACCEPT     all      usb0   br0     ::/0                 fe80::/64            state RELATED,ESTABLISHED
3        0     0 REJECT     all      *      *       ::/0                 ::/0                 reject-with icmp6-adm-prohibited

Chain OUTPUT (policy ACCEPT 36577 packets, 3195K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        7   969 ACCEPT     all      *      lo      ::/0                 ::/0
2        0     0 ACCEPT     all      *      br0     fe80::/64            fe80::/64
3        0     0 ACCEPT     all      *      usb0    fe80::213:ceff:fee8:c937  ::/0                 state NEW,RELATED,ESTABLISHED
4       18  1702 REJECT     all      *      *       ::/0                 ::/0                 reject-with icmp6-adm-prohibited
pi@rasphomefi:~ $ sudo ip6tables -t nat -L -v -n --line-numbers
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       31  2789 MASQUERADE  all      *      usb0    ::/0                 ::/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
pi@rasphomefi:~ $

J ' ai cru lire que certainnes personnes envoyaient justement des paquets invalides pour faire des detections le drop contrairement a reject-with icmp6-adm-prohibited renvoie des infos a un attaquant potentiel qui lui donnes des indications non ?

et derniere question , comment je peux preciser le reseau 192.168.42.0/24 sous la forme IPv6 svp ?
j ' ai mis ca : "fe80::213:ceff:fee8:c937" mais bon , suis pas certain que ca soit bon ...

Dernière modification par iznobe (Le 18/02/2021, à 09:30)

Zakhar · Le 18/02/2021, à 13:00

A ta place je ne m'amuserais pas avec le masquerade en ipv6 avant d'avoir lu et compris ce que ça fait.

Le fonctionnement d'ipv6 est assez différent d'ipv4 et tu n'as certainement pas envie de faire du "forward" sur du flux qui est sensé rester interne car sur fe80::

Comme je n'ai jamais étudié cette question (le forward en ipv6 par rapport à la notion de "hop") je te laisse la bûcher de ton côté...
J'ai cru voir que Free avait mis en place une sorte de "NAT V6" sur les Freebox, bien que l'ipv6 n'ait en théorie pas besoin de ça vu qu'on a assez d'ipV6 pour tout adresser, précisément pour retrouver deux choses :
- la protection NAT qu'on en V4
- le fait que les sites externes ne voient qu'une ip unique pour tous les appareils derrière une box.

Ce dernier point est intéressant pour certains services. Par exemple je suis client de 1fichier.com, où je stockes entre autres mes sauvegardes de façon commode grâce au driver que j'ai écrit : [1fichier] "Montez" votre stockage 1fichier en une commande simple !.
1fichier.com limite la "triche", c'est à dire évite qu'un abonnement soit "partagé" à plein d'utilisateurs, en se basant sur l'adresse IP. Donc même un client payant ne peut pas récupérer des sauvegardes à partir de deux ip.
Cela bloque les fonctionnement légitimes, par exemple si j'utilise à la fois mon RaspPi et mon PC en ipv6 ils vont avoir chacun une ipv6 différente et 1fichier.com interprète ça comme 2 utilisateurs et interdit le deuxième.
La solution "simple" est de forcer en ipv4 (mon driver le permet) et ainsi, merci la NAT, 1fichier.com ne voit que l'ipv4 de la Freebox qui est unique, et donc autorise les 2 téléchargements.
Sans doute que la "NAT V6" fait aussi ce genre de chose sur la Freebox (pas testé)... mais est-ce une chose dont tu as besoin ?

Donc tu ne veux que des règles d'input et uniquement sur usb0 et laisser le reste en paix !..

Pour le drop/reject oui, c'est toi qui vois protection/performance.

Dernière modification par Zakhar (Le 18/02/2021, à 13:08)

iznobe · Le 18/02/2021, à 14:02

Re ,
c ' est clair qu ' il y a un truc que j' ai pas compris dans le fonctionnement d ' IPv6 .
dejà j ' avoue avoir eu du mal a tout bien comprendre avec l' ipv4 , alors dejà la notation hexadeciamle et leur regle d ' ecriture c ' est pas evident .
De plus comme le fonctionnement est different , il faut en quelque sorte re-apprendre ... j ' ai beau avoir lu tout les articles ipv6 sur wikipedia et pas moyen de comprendre tout ! specialement les liens locaux pas compris les specificités .

je creuserai un peu plus ce soir sur ce sujet en esperant trouver un truc en français et clair .

si j' ai bien compris , il vaut mieux supprimer toutes les regles ipv6 des tables filter et nat pour le FORWARD ?
et envoyer la commande :

sudo ip6tables -A FORWARD -j REJECT --reject-with icmp6-adm-prohibited

qu ' est ce qu ' une adresse routable ( ou non ) svp ?

Dernière modification par iznobe (Le 18/02/2021, à 14:08)

Zakhar · Le 18/02/2021, à 15:17

L'ipv6 définit plus clairement que l'ipv4 les "classes" d'adresses.

En gros, tu as
l'adresse de boucle ::1 qui ne sort pas de ton PC (en ipv4 127.0.0.1)

les "link local" qui n'ont de sens que sur un lien fe80::1. Ces adresses sont valables uniquement sur un "lien" par exemple un fil ethernet entre 2 machines. Mais le "lien" peut aussi être le fil virtuel aérien pour la Wifi. Comme elles n'ont de sens que sur un lien, tu peux avoir plusieurs fois la même si tu as plusieurs interfaces. Ton Pi pourrait très bien avoir fe80::1 à la fois sur eth0 et sur wlan0. Pour distinguer quand c'est nécessaire on doit alors écrire fe80::1%eth0
D'ailleurs si tu veux faire un ping6 sur un "link-local" il te faudra préciser l'interface, même si tu n'as que des link-local distinctes, sinon ping6 donnera une erreur.
Ces adresses là ne "sortent jamais" du lien, donc pas de risque d'intrusion dans ton réseau local, sauf si tu as peur qu'au bout d'un lien il y ait une machine douteuse : exemple un ami que tu autorises à se connecter avec une machine W$ à ton réseau (mauvaise idée vu l'état de pourrissement par virus de ces machines).

Ensuite tu as les adresses de site (me souviens plus leur numérotation) qui sont valables sur "un site". Utile en entreprise.

Site + local pourrait être vu comme les équivalents 10.n.n.n ou 192.168.0.n de l'IPv4 mais l'équivalence n'est pas parfaite. En effet tu ne peux par exemple pas attribuer 192.168.0.1 à 2 interfaces de ton PC, alors que tu peux parfaitement attribuer fe80::1 à autant d'interfaces que tu veux (même si ce n'est pas forcément pratique de faire ça, la norme ne l'interdit pas).

Et en dernier les adresses "globales" qui sont universellement routables. Ce sont en ipv4 les ip que t'attribue ton FAI.
Pour une protection vis à vis "de l'extérieur", c'est de celles-là que tu veux te protéger, et donc uniquement ce qui va arriver en INPUT via usb0 (en dehors des réponses aux paquets ipv6 émis par les machines connectées à ton réseau : related, establish)

Tout ça est bien plus précisément expliqué là : https://perso.esiee.fr/~perrotol/IPv6-PocketGuide.pdf

Dernière modification par Zakhar (Le 18/02/2021, à 15:24)

iznobe · Le 19/02/2021, à 08:14

Bonjour et encore merci pour tout ces details .
le lien a l' air bien expliqué , je comprends l' anglais , mais quand ca devient technique j ' ai beaucoup de mal ...
je vais essayer de trouver ca en francais , sinon j ' utiliserai un traducteur pour mieux comprendre.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 15/02/2021, à 17:06

securisé son " routeur perso "

#2 Le 15/02/2021, à 18:58

Re : securisé son " routeur perso "

#3 Le 15/02/2021, à 19:31

Re : securisé son " routeur perso "

#4 Le 15/02/2021, à 20:42

Re : securisé son " routeur perso "

#5 Le 15/02/2021, à 20:57

Re : securisé son " routeur perso "

#6 Le 15/02/2021, à 21:15

Re : securisé son " routeur perso "

#7 Le 15/02/2021, à 21:23

Re : securisé son " routeur perso "

#8 Le 15/02/2021, à 21:35

Re : securisé son " routeur perso "

#9 Le 16/02/2021, à 14:28

Re : securisé son " routeur perso "

#10 Le 16/02/2021, à 20:50

Re : securisé son " routeur perso "

#11 Le 16/02/2021, à 21:43

Re : securisé son " routeur perso "

#12 Le 17/02/2021, à 07:55

Re : securisé son " routeur perso "

#13 Le 17/02/2021, à 12:49

Re : securisé son " routeur perso "

#14 Le 17/02/2021, à 15:55

Re : securisé son " routeur perso "

#15 Le 17/02/2021, à 18:16

Re : securisé son " routeur perso "

#16 Le 18/02/2021, à 08:05

Re : securisé son " routeur perso "

#17 Le 18/02/2021, à 09:00

Re : securisé son " routeur perso "

#18 Le 18/02/2021, à 09:22

Re : securisé son " routeur perso "

#19 Le 18/02/2021, à 13:00

Re : securisé son " routeur perso "

#20 Le 18/02/2021, à 14:02

Re : securisé son " routeur perso "

#21 Le 18/02/2021, à 15:17

Re : securisé son " routeur perso "

#22 Le 19/02/2021, à 08:14

Re : securisé son " routeur perso "

Pied de page des forums