Bonjour Stéphane > Quand tu parles de « désactiver un vdom » : tu as fait quoi exactement ?
Depuis l'interface graphique VDOM->VDOM->Edit->Disable > Tu n’as pas indiqué non plus le modèle du FG et les features activés. En l'occurence il s'agit d'un fortigate 100-D. Pour le client en question, aucune feature spécifique n'est activé (il matche une règle du type any-any accept).D'autres IP du subnet ont l'IPS d'activé. > Ma supposition est que tu avais une saturation CPU. J'avais écarté cette supposition que je m'étais faite (cf. suite) > Quand tu dis que la charge cpu est passée à 40%, l’info n’est pas précise > parce que je suppose que c’est une moyenne (tu peux avoir des pics à 100% qui > disparaissent de tes graphes) Cette hypothèse est peu probable : on a une supervision assez agressive sur l'état du(des) CPU(s). Cette ci se déclence notamment dès que l'on se connecte sur l'interface graphique et que tous les graphes s'affichent (ce qui n'a pas d'impact sur le trafic). On aurait eu des alarmes sans aucun doute si il était monté, même temporairement, à 100% > et si ton fg est multicpu : on n’a pas l’info précise par CPU. > Ma supposition est que tu avais une saturation CPU. (bis) Je reviens sur cette supposition, pendant l'attaque la charge CPU était environ 20-25% supérieure à l'habitude. Pour un firewall qui a 4 CPU, la valeur est troublante. J'aurais donc le CPU0 à 100% et les 3 autres qui ne font rien? Piste très intéressante. Gautier AVRIL ________________________________________ De : [email protected] [[email protected]] de la part de Stéphane C. [[email protected]] Envoyé : jeudi 20 novembre 2014 15:41 À : [email protected] Objet : Le: [FRnOG] [TECH] Comportement étrange Firewall / routeur Bonjour Gautier, Quand tu parles de « désactiver un vdom » : tu as fait quoi exactement ? Tu n’as pas indiqué non plus le modèle du FG et les features activés. L’idéal aurait été d’avoir une capture du trafic envoyé par le serveur pour comprendre ce qui s’est passé. Ma supposition est que tu avais une saturation CPU. Quand tu dis que la charge cpu est passée à 40%, l’info n’est pas précise parce que je suppose que c’est une moyenne (tu peux avoir des pics à 100% qui disparaissent de tes graphes) et si ton fg est multicpu : on n’a pas l’info précise par CPU. Tu peux avoir des CPU qui pioncent et un CPU qui sature … il suffit que le CPU qui sature soit le CPU qui gère le routage dynamique + processus kernel & userspace (a priori cpu0) et c'est tout ton boitier qui trinque. Un problème courant serait que ton serveur attaqué génère du trafic qui nécessite d’être traité par le FW en CPU (le NPU envoi les interruption au même CPU sans les ventiler correctement. Si ce CPU est le cpu0 : tu impactes ta ha, ton routage dynamique et autres "processus mgmt"). La fragmentation, les tempêtes de broadcast, etc. sont par exemple traités en CPU. (Et je ne parle pas de L7) Commandes utiles : 1) #diag hardware sysinfo interrupts (pour voir les interruptions NPU => CPU et la répartition) 2) #conf sys npu #set dedicated-management-cpu enable #end (pour que les interruption NPU ne soient plus envoyées au CPU0 et n’impacte pas les processus « user-space et kernel » qui consomment le CPU0) Bon courage @+ Stephane CROISY --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
