pare-feu Règles de sécurité, VPN et IPs

[CMDC]

Il y a 19 heures, CyberFr a dit :

Concernant le pare-feu je vois que toutes les règles sont dans l'interface LAN1 y compris les IP utilisées par VPN Server (10.0.0.0/255.0.0.0). Les autres interfaces ne sont pas utilisées y compris l'interface VPN le cas échéant ?

Je suis tout à fait d'accord avec toi au sujet de la règle  (10.0.0.0/255.0.0.0). qu'il ne faut absolument pas mettre dans l'interface LAN1; c'est contre les règles élémentaires de protection contre le SPOOFING ; SOURCES  ; si un attaquant arrive avec ce type d'adresse, c'est la "fête du slip" pour lui .

Il faut l'intégrer aux règles de l'interface VPN comme par exemple ceci (car je n'utilise qu'OpenVPN)

 

et surtout bien cocher la case Refuser accès

Modifié le 11 octobre 2023 par CMDC83

[PiwiLAbruti]

Il me semble que la section VPN du pare-feu concerne les connexions VPN clientes crées sur le NAS (NordVPN, ...). Elle n'aurait donc rien à voir avec VPN Server.

[CMDC]

Teste et tu verras, car c'est ainsi que cela fonctionne chez moi 

tun0 étant l'interface VPN server

[.Shad.]

@CMDC83 Je ne comprends pas ton propos, la partie spoofing dont tu parles concerne les attaques sur ton IP publique, dans ce cas on parle de plage d'IP bogon, les ranges d'IP qui n'ont pas vocation à apparaître dans les échanges publiques, dont les plages d'IP privées définies par la RFC1918 ainsi que certains autres blocs Bogon IP addresses, ipv4 and ipv6 bogon IP Ranges (ipgeolocation.io)
Sauf à ce que ton NAS établisse une connexion PPPoE directe avec ton fournisseur d'accès, cas qui n'est pas prévu par le tutoriel, il ne dispose pas d'une IP publique IPv4.
Et tout les fournisseurs d'accès intègrent dans leurs box les règles de drop pour le spoofing.

10.0.0.0/8 est dans l'extrême majorité utilisé par les réseaux VPN.
Or, pour la portabilité des noms de domaine, il est pratique de pouvoir atteindre une adresse en 192.168.0.0/16 depuis 10.0.0.0/8.
Si tu établis un serveur VPN chez toi pour te connecter de manière sécurisée, je ne vois aucun problème à autoriser cette plage d'adresses.
Les utilisateurs plus avancés pourront mettre en place un serveur DNS local avec des vues VPN et LAN séparées.
Mais ce tutoriel va à une solution plus simple avec très peu de (voire aucun selon moi) compromis sur la sécurité.

Modifié le 11 octobre 2023 par .Shad.

[CMDC]

Vaste débat ! 
Il est en effet peu probable qu'un hacker utilise ce type d'adresse ! Sauf si ....     ... On ne connait pas forcément les limites du génie des hackers.
Ce qui fait qu'il faut produire des règles le plus restrictives possible !
Donc changer la règle par défaut de l'interface VPN en Refuser l'Accès et donc forcement ajouter la règle d'accès par le  réseau 10.0.0.0/8 si on utilise un VPN.

Après, chacun fait ce qui lui plait hein ? 

EDIT> En tout cas merci pour ce superbe tuto @.Shad.

Modifié le 11 octobre 2023 par CMDC83

[.Shad.]

Je comprends tout à fait ta remarque, mais ce tutoriel n'a pas pour vocation de pousser le cran de la sécurité au maximum.
Une fois les utilisateurs un peu plus aguerris, ils pourront tout à fait réduire par exemple la plage 192.168.0.0/16 à leur sous-réseau en particulier.
Même chose pour 10.0.0.0/8 avec le sous-réseau qu'ils vont utiliser avec leur éventuel serveur VPN.

Et comme tu dis, on peut tout à fait réduire la surface d'exposition par rapport à celle préconisée ici. L'idée est aussi qu'à la moindre d'installation de paquet, ils ne se retrouvent pas bloqués parce que les règles sont trop restrictives (je pense à VPN Server et Container Manager par exemple).

Les considérations que tu évoques pourraient probablement l'objet d'un tutoriel axé sur la sécurisation pour utilisateur avancé.

[PiwiLAbruti]

Il y a 3 heures, CMDC83 a dit :

Teste et tu verras, car c'est ainsi que cela fonctionne chez moi 

N'ayant jamais configuré de client VPN (type NordVPN, …) sur le NAS, la section VPN du pare-feu est restée telle quelle ("Autoriser l'accès" par défaut). Si on passe en "Refuser accès", les clients VPN de VPN Server n'ont plus accès aux ressources locales.

Quand on autorise l'accès aux ports locaux dans cette section, ça l'autorise pour tout le réseau local. Par exemple, le port tcp/80 permet aux clients VPN d'accéder aussi bien à WebStation qu'aux autres serveurs web du réseau local. C'est là qu'on voit les limites du pare-feu du NAS (absence de destination dans les règles).

J'ai vaguement fouillé la doc de Synology pour trouver des explications à ce comportement étrange (et apparemment global quelque soit le type de VPN client/serveur, sans distinction d'interface), et je n'ai rien trouvé.

Dans tous les cas, restreindre cette section dans le cadre de l'utilisation de VPN Server uniquement n'apporte pas rien de plus à la sécurité étant donné que les adresses IP utilisables sont définies dans VPN Server et que leur obtention est soumise à authentification.

Il y a 4 heures, CMDC83 a dit :

Je suis tout à fait d'accord avec toi au sujet de la règle  (10.0.0.0/255.0.0.0). qu'il ne faut absolument pas mettre dans l'interface LAN1; c'est contre les règles élémentaires de protection contre le SPOOFING ; SOURCES  ; si un attaquant arrive avec ce type d'adresse, c'est la "fête du slip" pour lui .

Ce n'est pas du tout applicable à la sécurité d'un NAS. La source que tu cites précise d'ailleurs que c'est à appliquer sur l'interface publique de routeur :

Citation

These rules block spoofed packets originating from private (local) subnets. On your public network interface you usually don’t want to receive packets from private source IPs.

C'est pour éviter le spoofing sur une interface publique de type CG-NAT.

[CMDC]

On en vient donc à la fameuse règle du normalement !
Normalement on ne devrait pas recevoir des IP "non normalisées" .... Normalement, sauf que .....

Un exemple ?
j'ai implémenté les fameuses règles DDoS que je cite une peu plus haut sur mes NAS ; voilà le résultat des courses :

On s'aperçoit que "normalement" on rejette des IP en 0.0.0.0/8 et en 192.168.0.0/16

En en revient donc , en SSI , à rejeter cette règle du "normalement"

 

My two cents !

[PiwiLAbruti]

Ouais en fin là, sans plus analyser l'origine, ça n'a aucun sens.

L'un des cas d'utilisation du réseau 0/8 est DHCP où le client utilise une adresse de ce réseau comme source (par ce qu'il en faut bien une) pour broadcaster sa demande d'adressage. Si tu utilises DHCP pour adresser une partie des machines de ton réseau local, les 6075 drops proviennent des demandes DHCP des différents appareils de ton réseau local.

Je ne vais pas m'étendre sur le reste des blocages dont les origines sont tout aussi légitimes que celle expliquée ci-dessus. Si les origines ne le sont pas, le réseau 0/8 n'étant pas routable, le réseau local serait alors complètement compromis.

L'analyse est un des gros blocs de la SSI sur la sécurisation des réseaux. C'est grâce à ça qu'on dimensionne des moyens de sécurité pertinents à mettre en face. Sans ça, on se retrouve à mettre de la sécurité à outrance là où ce n'est pas utile et à titrer des conclusions farfelues.

[CMDC]

Si tu nous balance 15 lignes d'analyse sur le première ligne de ma copie d'écran avec l'analyse des CSTATE invalid  , c'est bien !

et les 214 autres ? et les intrusions en 192.168.0.0 ?
Puis-je me permettre ?

Humilité , humilité et enfin humilité ! 
Surtout ne rien négliger !

 

[PiwiLAbruti]

Le 10/11/2023 à 10:04 PM, CMDC83 a dit :

et les 214 autres ? et les intrusions en 192.168.0.0 ?
Puis-je me permettre ?

J'ai autre chose à faire que d'analyser du trafic légitime sur ton réseau local.

Et apparemment tu as les compétences nécessaires pour faire cette analyse par tes propres moyens, donc fais nous un rapport détaillé du trafic illégitime provenant d'adresses de ton réseau local.