Avis important : |
La série Zyxel Firewall à partir de la version 5.35 du firmware
Un pare-feu est la première ligne de défense contre les attaquants provenant d'Internet. Il protège le réseau local contre les accès non autorisés et constitue un élément essentiel d'un concept de sécurité. Mais que faire si le pare-feu lui-même devient la cible d'attaques de pirates et peut donc devenir une menace potentielle ? Le guide suivant a pour but de fournir des informations sur la manière d'attaquer les possibilités qui peuvent être restreintes.
1. Contrôle de la politique
2. Détection et prévention des anomalies
3. Gestion à distance via HTTPS
4. Authentification à deux facteurs
5. Journaux d'alerte
6. Mises à jour automatiques du micrologiciel
7. Protection des données sensibles
1. Contrôle de la politique
Aussi peu d'utilisateurs que nécessaire doivent avoir accès au pare-feu. Pour y parvenir, il est conseillé de restreindre les droits d'accès autant que possible.
Configuration > Politique de sécurité > Contrôle des politiques
La zone ZyWALL joue un rôle particulier. Elle contient toutes les adresses d'interface du pare-feu. Seules des règles peuvent être créées pour cette zone.
Par exemple, l'adresse par défaut 192.168.1.1 n'appartient pas à la zone LAN1 mais à la zone ZyWALL.
Avec les paramètres par défaut, l'accès au pare-feu est principalement ouvert. Il convient donc de les restreindre davantage.
Restriction des règles de contrôle de la politique
Les règles du pare-feu peuvent être limitées en fonction de plusieurs critères. Principalement, trois critères sont utiles pour l'accès au pare-feu :
1. Source IPv4 (objets d'adresse)
2. le service
3. utilisateur
Ces éléments sont créés en tant qu'objets.
Objets d'adresse
Il existe fondamentalement trois types d'objets adresse. Ce sont :
1. Les adresses IP
2. Les adresses FQDN
3. Adresses GeoIP
Les objets adresse peuvent être regroupés. Cependant, il n'est pas possible de mélanger différents types d'adresses.
Configuration > Objet > Adresse/Geo IP > Adresse
1.1 Adresses IP
Les adresses IP doivent être utilisées autant que possible, car elles sont uniques. Il existe plusieurs types d'adresses IP :
1. host > elle décrit une adresse IP unique
2. plage > il peut s'agir de n'importe quelle plage définie par les adresses de début et de fin.
3. sous-réseau > il peut être créé en saisissant un masque de sous-réseau ou un CIDR (par exemple /24).
4. interface IP > reprend l'adresse IP d'une interface et s'adapte dynamiquement.
5. interface subnet > reprend dynamiquement le sous-réseau d'une interface
6. interface gateway > reprend la passerelle d'une interface de type WAN ou générale.
Hôte, Plage, Sous-réseau
Les types d'adresses Host, Range et Subnet sont particulièrement adaptés comme sources IPv4. Si l'accès se fait depuis le WAN, l'adresse IP publique de la station distante est spécifiée.
Depuis un LAN, ces objets peuvent être utilisés pour créer des groupes avec des autorisations différentes.
Interface IP
Cet objet peut être utilisé si l'accès n'est possible que sur une adresse IP spécifique. Par exemple, s'il y a 2 interfaces WAN, mais qu'un service ne doit être disponible que sur une seule interface, l'IP de l'interface peut être entrée dans la règle de contrôle de la politique comme une destination IPv4.
Sous-réseau d'interface
Ce type d'adresse convient si des règles uniformes doivent être créées pour une interface locale (par exemple LAN1).
Passerelle d'interface
Ce type d'adresse n'est pas pertinent pour l'accès au pare-feu.
2. Objets FQDN
Les objets FQDN permettent de saisir un nom à la place d'une adresse IP, par exemple www,mondomaine.com. Ce type d'entrée est particulièrement adapté si l'accès se fait depuis le WAN et que la station distante ne dispose pas d'une adresse IP publique statique. Dans ce cas, un nom DynDNS peut être utilisé à la place de l'adresse IP. Pour les objets FQDN, un serveur DNS rapide est nécessaire. Les entrées joker telles que *.mydomain.com sont également possibles. Cependant, elles ne peuvent pas être utilisées à cette fin.
1.2 Objets FQDN
Les objets FQDN permettent de saisir un nom à la place d'une adresse IP, par exemple www,mydomain.com. Ce type d'entrée est particulièrement adapté si l'accès se fait depuis le WAN et que la station distante ne dispose pas d'une adresse IP publique statique. Dans ce cas, un nom DynDNS peut être utilisé à la place de l'adresse IP. Pour les objets FQDN, un serveur DNS rapide est nécessaire. Les entrées joker telles que *.mydomain.com sont également possibles. Toutefois, elles ne peuvent pas être utilisées à cette fin.
Adresses Geo IP
L'adresse IP géographique peut être utilisée pour créer des objets basés sur un pays ou une région. Ce service utilise une base de données externe et doit être mis à jour régulièrement. Les Geo IP n'offrent pas une protection fiable, car l'adresse source peut être manipulée très facilement à l'aide de services VPN disponibles gratuitement.
Objets de service
Les objets de service sont utilisés pour définir les services auxquels l'accès est accordé ou refusé dans les paramètres de contrôle de la politique. Les services peuvent être regroupés. Les services peuvent également être utilisés ailleurs, par exemple dans les routes de politique et les entrées NAT.
En plus des objets de service standard, il existe quelques objets particuliers. Ce sont les objets "Wiz_2FA, Wiz_HTTP, Wiz_HTTPS et Wiz_SSLVPN". Le port de ces services s'adapte automatiquement lorsqu'il est redéfini dans le menu correspondant.
Configuration > Objet > Service
Utilisateur
Configuration > Objet > Utilisateur
Il existe différents types d'utilisateurs.
Admin - peut apporter des modifications à la configuration
Limited-admin - peut accéder à la configuration mais ne peut pas apporter de modifications.
Utilisateur - peut s'authentifier à l'aide de 2FA
Guest - peut se connecter au pare-feu
Ext-user/ext-group-user - peut s'authentifier auprès d'un serveur externe.
Les utilisateurs intégrés sont des utilisateurs prédéfinis qui ne peuvent pas être supprimés et qui sont destinés à des fins spécifiques.
Les utilisateurs doivent être définis de manière à ce qu'ils ne disposent que des autorisations nécessaires.
Généralement, les utilisateurs VPN ou 802.1x sont définis comme des utilisateurs de type Users.
Sécurité de la connexion
Définit si et dans quelle période les mots de passe doivent être changés et si la complexité des mots de passe est requise.
Paramètres de connexion de l'utilisateur
Définit combien de fois un utilisateur peut se connecter en même temps. Si la limite est fixée à "1", un administrateur peut se verrouiller.
Paramètres de verrouillage de l'utilisateur
Ces paramètres définissent le nombre de fois où une saisie erronée du mot de passe est autorisée jusqu'à ce que l'utilisateur soit bloqué pendant une certaine période. Ce paramètre permet de se protéger contre les attaques par force brute.
Règles de contrôle de la politique recommandées
De : WAN Vers : ZyWALL
Il est fortement recommandé de fermer tous les services qui ne sont pas spécifiquement nécessaires.
Services fréquemment utilisés :
VPN IPSec (IKEv1, IKEv2, L2TP) :
ESP, IKE, NATT, (L2TP-UDP).
VPN SSL :
Wiz_SSLVPN
Authentification à 2 facteurs pour VPN :
Wiz_2FA
Accès à distance via HTTP/HTTPS :
Wiz_HTTP, Wiz_HTTPS
Pour éviter au maximum les risques de sécurité, la télégestion est idéalement réalisée via un VPN IPSec. Les adresses sources doivent être limitées si possible. Le VPN SSL n'est pas recommandé, car il offre un vecteur d'attaque possible via SSL.
Accès à distance via HTTPS :
Si un accès à distance via HTTP/HTTPS est nécessaire, l'adresse source doit toujours être limitée à une adresse IP ou à un FQDN. Le GeoIP comme adresse source n'est pas sécurisé et offre un potentiel d'attaque important. Pour la gestion HTTPS, il est recommandé d'utiliser un autre port.
De : Zone VPN Vers : ZyWALL (client à site)
Par défaut, tous les ports sont ouverts. Dans la plupart des cas, seuls quelques services sont nécessaires. Il s'agit, par exemple, du DNS et de L2TP-UDP. Pour les autres services, l'accès doit être bloqué. Si la gestion à distance via un VPN client-site est souhaitée, l'accès au pare-feu peut être limité à un seul utilisateur. Toutefois, cela ne fonctionne que si l'utilisateur s'est déjà connecté au pare-feu lors de la mise en place du tunnel.
De : LAN Vers : ZyWALL
Ici aussi, les droits d'accès doivent être limités. L'accès complet au pare-feu ne doit être accordé qu'à un réseau local de gestion spécial ou à des adresses IP d'administrateurs individuels. Pour que certains services fonctionnent correctement, l'accès au pare-feu doit être accordé. Il s'agit notamment des services DNS, multicast, Radius-Auth, NetBIOS, SNMT, SSO, etc. Les accès effectivement requis dépendent fortement de la topologie du réseau et des technologies utilisées.
2. Détection et prévention des anomalies (ADP)
Configuration > Politique de sécurité > ADP
ADP offre une protection contre les analyses de ports et les comportements inhabituels sur le réseau. Il est recommandé d'activer ADP avec le profil par défaut de la zone WAN. Des ajustements individuels peuvent être apportés au profil en cas de problèmes.
Dans certains cas, ADP peut affecter certains services. Cela s'applique en particulier à la détection des inondations. Pour cette raison, la protection contre les inondations peut être désactivée pour certains services, par exemple NATT. Un tel réglage n'est utile qu'en cas de problèmes.
3. Gestion à distance via HTTPS
Certains réglages spécifiques dans les paramètres WWW ont un impact direct sur la sécurité du système.
Configuration > Système > WWW
Port du serveur
Le port standard 443 ne doit pas être utilisé pour la gestion à distance, car il est toujours scanné lors d'attaques automatisées. Les ports alternatifs fréquemment utilisés (par exemple 8443) ne sont pas non plus idéaux.
Rediriger HTTP vers HTTPS
Tous les appels HTTP vers l'interface graphique sont redirigés vers HTTPS. Attention. Ce paramètre ne doit pas être activé si l'authentification Web est utilisée. Dans tous les autres cas, cette option doit être activée.
Contrôle du service d'administration
Vous pouvez définir ici qui peut avoir un accès administrateur au pare-feu. Il serait préférable pour vous de limiter l'accès aux adresses IP individuelles. Seules les adresses IP sont autorisées comme objets d'adresse. Comme dernière règle (ici, la règle 5), une règle ALL/ALL/deny doit être créée. Il faut faire attention lors de la création de la règle afin de ne pas se bloquer. Par conséquent, les règles d'acceptation doivent être créées avant la règle de refus, qui est créée en dernier.
Contrôle du service utilisateur
Le contrôle du service utilisateur définit quels clients peuvent s'authentifier auprès du pare-feu.
Cette règle est pertinente pour SSL-VPN, 2-FA, VPN Configuration Provisioning et WEB-Authentication.
Si elle n'est pas utilisée, une règle de refus peut également être définie.
Authentifier les certificats du client
Si l'option Authentifier les certificats du client est activée, le client doit s'autoriser avec un certificat valide. Dans le cas contraire, la connexion sera refusée. Ceci s'applique à l'accès via HTTPS et SSL VPN. Configuration VPN_Profiler avec SecuExtender ne fonctionne pas si cette option est activée. Cependant, l'appel de la fenêtre 2FA est toujours possible sans certificat.
Pour qu'un certificat soit reconnu par le pare-feu, la chaîne de confiance de l'autorité de certification doit être installée. Celle-ci comprend généralement un certificat racine et un certificat intermédiaire. Le pare-feu fait confiance à tous les certificats dont la chaîne de confiance est valide, ainsi qu'à ses propres certificats auto-signés. Il convient de noter que certains navigateurs rejettent par principe les certificats auto-signés (actuellement les navigateurs basés sur Firefox). Le certificat du client ne doit pas être installé sur le pare-feu.
Configuration > Objet > Certificat > Certificats de confiance
4. Services de gestion à distance
Configuration > Système
Il existe plusieurs services sur le pare-feu qui sont rarement ou jamais nécessaires. Ces services peuvent être désactivés complètement.
SSH
Par exemple, ce service peut être utilisé lorsque des changements de configuration sont effectués avec un script automatique. Si SSH n'est pas utilisé régulièrement pour l'administration, le service peut être désactivé. La console Web peut également être utilisée à la place de SSH pour l'entrée CLI.
TELNET
Il n'est pas nécessaire dans la plupart des cas et peut être désactivé.
FTP
Via FTP, il est possible de mettre à jour le firmware ou de télécharger des fichiers de configuration. FTP doit être activé si HA-Pro est utilisé. Si ce n'est pas le cas, FTP peut être désactivé. Si le service est nécessaire de façon sporadique, il peut être activé temporairement.
SNMPLeservice est nécessaire pour la surveillance du réseau et est requis pour des solutions comme PRTG. Si le réseau n'est pas surveillé, le service peut être désactivé.
ZON
Permet l'échange d'informations avec les appareils voisins (modèle, nom, firmware, adresse MAC, adresse IP) via LLDP ainsi qu'avec le logiciel ZON de Zyxel dans le même LAN. Ce service n'est pas nécessaire pour un fonctionnement régulier.
VPN
VPNIPSec Site-à-Site
Lors de l'utilisation de tunnels site à site, une adresse de passerelle de pair doit être saisie dans la mesure du possible. Si le site distant a une adresse IP dynamique, un nom DynDNS peut également être utilisé. Un nom DynDNS peut également être utilisé si le site distant se trouve derrière un NAT/CG-NAT. Dans ce cas, il est important que la connexion soit établie du côté distant et que le service DynDNS synchronise l'adresse IP publique.
Pour l'authentification, un certificat est préférable à un PSK. Les points suivants doivent être pris en compte :
1. Le certificat utilisé peut être un certificat auto-signé mais doit être stocké sur le côté distant sous "Trusted Certificates".
2. Des deux côtés, un certificat propre est créé
3. Le type d'ID local est extrait du certificat et doit être saisi de manière identique à l'ID du pair de l'autre côté.
La recommandation pour la durée de vie maximale de la SA est de 86400 secondes dans la passerelle VPN et 14400 secondes dans la connexion VPN.
5. les paramètres suivants sont recommandés comme minimum pour le cryptage VPN : AES256 / SHA256 / DH15. Ceci aussi bien dans la passerelle VPN que dans la connexion VPN.
L'Extended Authentication Protocol est également possible pour les tunnels site à site. Cependant, l'utilisateur enregistré n'est pas connecté au pare-feu lorsque la connexion est établie.
IPSec Client-to-Site VPN
Pour le VPN client-site, il est recommandé d'utiliser IKEv2 avec le certificat et Extended Authentication Protocol.
Le Configuration Payload est obligatoire dans la connexion VPN.
Une fois la connexion établie, le client est connecté au pare-feu avec l'utilisateur. Pour tout accès admin au firewall, l'utilisateur admin correspondant peut ainsi être enregistré dans le contrôle de la politique.
L2TP-VPN
L'utilisation d'un VPN L2TP n'est pas recommandée. IKEv2 peut être utilisé à la place.
SSL VPN
En raison des performances et des problèmes de sécurité possibles, SSL VPN n'est pas recommandé. Cependant, comme il est populaire en raison de sa facilité de configuration, il faut envisager ce qui suit :
Configuration > VPN > VPN SSL > Réglage global
L'utilisation d'un port séparé pour le VPN SSL est obligatoire. En aucun cas, le port 443 ne doit être utilisé.
La sécurité est considérablement renforcée par l'utilisation d'un certificat pour l'authentification. La configuration est décrite sous "Gestion à distance via HTTPS > Authentifier le certificat du client".
Dans le Policy Control, il est conseillé de restreindre l'IP source pour l'accès du WAN au ZyWALL pour le service Wiz_SSLVPN. Au moins à une GeoIP, mieux à un FQDN ou une adresse IP.
De plus, l'accès de l'administrateur au pare-feu depuis la zone SSL-VPN peut être limité à l'utilisateur admin. Cela est possible parce que l'utilisateur se connecte déjà au pare-feu pendant la configuration du tunnel.
Les utilisateurs ordinaires n'ont pas besoin d'accéder au pare-feu à partir de la zone VPN SSL. Il suffit que les services typiques tels que le DNS soient autorisés ici.
5. Authentification à deux facteurs
L'authentification à deux facteurs est recommandée pour l'accès administrateur, de préférence avec Google Authenticator.
La configuration de l'authentification à deux facteurs doit être effectuée séparément pour chaque utilisateur. La méthode Google Authenticator est recommandée. Notez que les utilisateurs qui n'ont pas configuré 2FA peuvent toujours se connecter sans authentification supplémentaire. Pour cette raison, 2FA n'offre qu'une protection limitée.
2FA kann auch für VPN-Access aktiviert werden.
Zur Authentifizierung wird immer ein eigener Port verwendet (Objekt Wiz_2FA).
Il existe plusieurs méthodes pour vérifier si un lien est accepté. Pour toutes les méthodes, un lien doit être créé sur l'interface Web.
Da das WEB-GUI für 2FA aus dem WAN erreichbar sein muss, besteht hier auch ein potenzielles Angriffsrisiko. Aus diesem Grund ist diese Funktion mit Vorsicht zu geniessen.
La façon de configurer l'authentification à deux facteurs est décrite dans notre autre article :
Authentification à deux facteurs avec Google Authenticator pour l'accès administrateur.
6. Journaux d'alerte
Pour certaines options, il peut être utile de configurer un journal d'alerte. Dans ce cas, une notification par e-mail peut être déclenchée immédiatement lorsqu'un événement se produit. Cela peut être utile, par exemple, lorsqu'un administrateur se connecte, en particulier pour les pare-feu qui ne sont surveillés qu'à intervalles irréguliers.
Configuration > Journal & Rapport > Paramètres du journal
7. Mises à jour automatiques du micrologiciel
Il faut toujours veiller à ce que le micrologiciel du pare-feu soit à jour. Pour les systèmes qui sont activement maintenus, les mises à jour peuvent être effectuées manuellement. Cependant, dans la réalité, il arrive souvent que cette opération soit négligée et que les pare-feu présentant des failles de sécurité connues ne soient pas mis à jour sur une longue période.
. Surtout dans les environnements de ce type, il est recommandé d'activer les mises à jour automatiques pour des raisons de sécurité.
Maintenance > Gestionnaire de fichiers > Gestion des micrologiciels
8. Protection des données sensibles
À partir de la version 5.35 du micrologiciel, les mots de passe peuvent être chiffrés avec une clé personnalisée au lieu de l'algorithme par défaut. Les autres mots de passe utilisent toujours la méthode par défaut. Cette fonction permet également de se protéger contre la lecture des mots de passe utilisateur dans les fichiers de configuration à l'aide d'outils de piratage.
Maintenance > Gestionnaire de fichiers > Fichier de configuration > Configuration > Protection des données sensibles
Supposons que le fichier soit réinstallé sur un pare-feu. Ceci n'est possible qu'avec la clé.