D’accord, bienvenue à l’une des périodes les plus frustrantes de ma carrière de deux semaines.
Nous avons un SonicWall 2700, configuré par un MSP que nous utilisons depuis des années. Il a été installé début 2022 et fonctionnait parfaitement pendant une longue période.
À partir du 30 avril (il y a deux mardis), il a commencé un comportement où il semble arrêter de router le trafic à travers lui pendant environ 10 minutes. Nous avons passé beaucoup de temps à nous demander s’il pourrait s’agir d’un autre équipement, car il n’y a aucun problème apparent sur l’appareil lui-même. Du moins pas de problème visible selon notre MSP ou un consultant externe. Nous avons trouvé quelques autres problèmes apparemment sans rapport sur notre réseau. Mais après avoir supposé “que cela doit être ça”, nous avons attendu et déterminé que ce n’était en fait pas le problème.
Je suis maintenant à un point où je demande à Reddit si quelqu’un a déjà vu un comportement comme celui-ci ? Nous subir des attaques VPN de plus en plus fréquentes (comme tout le monde) mais je n’ai pas vu de signe qu’elles empirent et qu’elles finissent par faire céder quelque chose. Il est notable que le problème semble ne se produire que pendant les heures de travail et seulement en semaine.
Il semble toutefois s’être éventuellement amélioré, dans la mesure où nous sommes passés de plusieurs occurrences le lundi, mardi et mercredi de la semaine dernière et cette semaine. Cette semaine, nous avons eu deux occurrences lundi, une mercredi et une vendredi.
Cela correspond-il à quelque chose que d’autres ont vu ?
SonicWall nous a fait appliquer une mise à jour du firmware et un correctif rapidement, pensant que cela correspondait à une erreur qu’ils ont récemment vue avec des unités configurées en HA (ce qui était le cas, nous avons actuellement désactivé la HA pour réduire les variables).
Est-ce que ça vous semble familier ? Et avez-vous des idées lumineuses sur ce qui pourrait se passer ?
Quelle version du firmware votre SonicWall utilise-t-il ? Si vous êtes en dessous de 7.1.1, ouvrez un cas avec SonicWall et obtenez un correctif 7.1.1-7051 ou plus récent. C’est un problème connu avec les attaques par force brute sur votre portail VPN SSL ou votre box SMA, etc.
Je vous recommande d’activer le blocage géographique sur vos services exposés publics.
Téléchargez le TSR (rapport de service technique)
Et nous recherchons 2 choses – l’historique du firmware et les messages de redémarrage du watchdog.
L’historique du firmware, si plusieurs versions d’updates sont listées, sauvegardez la config, réinitialisez aux paramètres d’usine, puis restaurez cette config. Cela a résolu plusieurs problèmes étranges.
Les messages du watchdog peuvent indiquer pourquoi il redémarre.
Nous avons aussi découvert que le flux de Netflow vers un collecteur local causait des redémarrages dans les versions 7.0.1 et il fallait le désactiver.
Désolé pour ce long message…
Sans connaître sa configuration et son utilisation, nous ferons des suppositions à l’aveugle, et étant en production, vous ne serez pas disposé à “essayer ceci” ou “essayer cela”.
Il est possible que la capacité de débit offert par le NSA2700 soit désormais trop faible pour vous, et que vous deviez peut-être passer à un modèle supérieur. Les réseaux croissent, chaque nouvel endpoint ajoutant de la charge.
Débit d’inspection du pare-feu 5,2 Gbps
Débit de prévention des menaces 3,0 Gbps
Débit d’inspection d’application 3,6 Gbps
Débit IPS 3,4 Gbps
Débit d’inspection anti-malware 2,9 Gbps
Débit d’inspection TLS/SSL et déchiffrement (DPI SSL) 800 Mbps
Débit VPN IPSec 2,10 Gbps
Il se pourrait aussi que tous les ports soient utilisés mais les trunks soient pleins, utilisez-vous les ports SFP ?
Nous utilisons 2 ports SFP pour la WAN et 2 ports SFP pour le LAN principal, tous les autres ports gigabit sont utilisés pour des segments spécifiques. Si vous utilisez seulement les ports gigabit, envisagez d’utiliser les SFP pour la dorsale des trunks LAN, cela pourrait résoudre le problème.
Il pourrait aussi y avoir une boucle de routage, causée par un câblage incorrect ou des endpoints multi-homed connectés à deux switches différents. Activez STP sur tous les switches pour éviter cela.
Vérifiez la logique du câblage, cela peut prendre du temps mais améliorera votre réseau.
Pour les attaques, configurez une règle de rejet dans la politique de sécurité, activez la géo-IP, bloquez les pays étrangers, et utilisez des objets pour les IP sources/destinations.
Nous avons connu des blocages aléatoires et le pare-feu devient totalement instable, incapable de passer le trafic ou d’être accessible via la gestion hors bande ou le port LAN. Nous sommes en firmware 7.1.1 et avons appliqué le correctif pour les attaques par force brute. SonicWall est une vraie pagaille.
Il s’agit déjà d’un problème signalé en 7.1.1, contactez le support technique et demandez le correctif. SonicWall a publié deux articles KB pour ce problème, pour GEN-6 et GEN-7.
J’ai dû désactiver LDAP sur un SonicWall récemment car il ne bloquait pas après plusieurs tentatives échouées. J’ai transféré tous les utilisateurs vers des comptes locaux sur le pare-feu.
Il est actuellement sur SonicOS 7.1.1-7051-R563. SonicWall nous a fait faire la mise à jour le lendemain du début du problème.
Auparavant, il était sur 7.0.1-5095-R3599 depuis un peu plus d’un an. La géo-blocage est difficile pour nous car beaucoup de nos employés voyagent à l’étranger.
Ce n’est pas du tout un problème thermique. J’ai pu me connecter à la firewall depuis le LAN pendant qu’il se passait, donc l’interface fonctionne quand c’est bloqué.
Les tests que j’ai effectués montrent que je peux me connecter à la gestion depuis le LAN, mais il n’y a pas d’indication évidente dans les logs ou graphiques d’un problème. Tout semble fonctionner sauf que le trafic LAN/WAN ne passe pas.
Les ports ou interfaces spécifiques arrêtent-ils de fonctionner pendant 10 minutes ou tout l’équipement ? L’accès LAN fonctionne-t-il pour le routage vers le WAN ? Il pourrait y avoir une défaillance matérielle. Après avoir testé, vérifiez si la durée d’usage est normale et si la mémoire et le CPU sont en ordre.
Je n’ai pas accès aux données SNMP, mais on m’a dit que tout va bien côté CPU et bande passante. On voit des erreurs WLB dans les logs récemment, mais cela pourrait venir d’un changement de configuration ou d’un switch intermédiaire. Les erreurs de « probe failed » apparaissent aussi, mais elles disparaissent rapidement si on intervient. On a débranché et rebranché le câble Ethernet entre le firewall et le routeur pour réduire le délai d’indisponibilité, mais cela n’a pas résolu le problème à long terme.
Je ne suis pas sûr de pourquoi le WLB était activé puisque nous n’avons qu’une seule connexion reconnue par le SonicWall. On a désactivé cette option lors d’un incident, mais cela n’a pas changé la situation. La prochaine étape est de tester avec un pare-feu de secours, de le reconstruire et de le remplacer.