Pourquoi les sessions affichent-elles l’application « indécise » lorsqu’elles sont en état ACTIVE mais ont une application lorsqu’elles sont déplacées vers DISCARD l’État ?
49803
Created On 03/30/19 02:33 AM - Last Modified 03/26/21 17:32 PM
Question
Pourquoi certaines sessions montrent-elles l’application comme « indécise » alors qu’elles sont dans un état mais montrent ACTIVE une application après avoir déménagé à l’État? DISCARD
Environment
Dans certains cas, vous pouvez voir que les sessions s’affichent comme « indécises » lorsque l’état de la session est ACTIVE . Puis, ils se présentent plus tard avec un nom d’application.
Voici un exemple du moment où la session est dans le ACTIVE STATE :
> show session id 74569901 Session 74569901 c2s flow: source: 10.1.1.1 [Internal_Clients] dst: 192.168.1.1 proto: 6 sport: 28156 dport: 80 state: ACTIVE type: FLOW src user: unknown dst user: unknown s2c flow: source: 192.168.1.1 [Internal_Servers] dst: 10.1.1.1 proto: 6 sport: 80 dport: 28156 state: ACTIVE type: FLOW src user: unknown dst user: unknown Slot : 1 DP : 2 index(local): : 7461037 start time : Wed Jul 18 09:39:00 2018 timeout : 90 sec time to live : 6 sec total byte count(c2s) : 1238 total byte count(s2c) : 144 layer7 packet count(c2s) : 3 layer7 packet count(s2c) : 2 vsys : vsys3 application : undecided <<<<<
Une fois la session passée à DISCARD l’état :
> show session id 74569901 Session 74569901 c2s flow: source: 10.1.1.1 [Internal_Clients] dst: 192.168.1.1 proto: 6 sport: 28156 dport: 80 state: DISCARD type: FLOW src user: unknown dst user: unknown offload: Yes s2c flow: source: 192.168.1.1 [Internal_Servers] dst: 10.1.1.1 proto: 6 sport: 80 dport: 28156 state: DISCARD type: FLOW src user: unknown dst user: unknown offload: Yes Slot : 1 DP : 2 index(local): : 7461037 start time : Wed Jul 18 09:39:00 2018 timeout : 90 sec time to live : 6 sec total byte count(c2s) : 1238 total byte count(s2c) : 144 layer7 packet count(c2s) : 3 layer7 packet count(s2c) : 2 vsys : vsys3 application : web-browsing
Answer
Dans ces cas, nous devons d’abord comprendre pourquoi la session est entrée dans l’état de rejet.
Si l’application est bloquée par la policy sécurité, ce comportement est attendu aussi longtemps. Comme App- ID n’est pas en mesure de déterminer l’application exacte, une session peut firewall être autorisée par le biais de l’indécis jusqu’à ce que l’application est identifiée, au moment où les règles de sécurité sont réévaluées et une mesure appropriée est prise, ce qui pourrait être de rejeter la session.
> show session id 74569901 Session 74569901 c2s flow: source: 10.1.1.1 [Internal_Clients] dst: 192.168.1.1 proto: 6 sport: 28156 dport: 80 state: DISCARD type: FLOW src user: unknown dst user: unknown offload: Yes s2c flow: source: 192.168.1.1 [Internal_Servers] dst: 10.1.1.1 proto: 6 sport: 80 dport: 28156 state: DISCARD type: FLOW src user: unknown dst user: unknown offload: Yes Slot : 1 DP : 2 index(local): : 7461037 start time : Wed Jul 18 09:39:00 2018 ****cut for brevity**** session QoS rule : N/A (class 4) tracker stage firewall : appid policy lookup deny end-reason : policy-deny
Une autre cause pourrait être la contention des ressources.
Lorsque le système est imposé au point qu’il n’y a pas assez de ressources pour compléter app- ID , avant de mettre fin à l’inspection layer-7, le fait une firewall ID application-recherche, qui utilise des informations basées sur le port, mais ce n’est peut-être pas une application exacte identifiée.
L’étape « tracker firewall » déterminera si la session s’est terminée en raison de la contention des ressources.
> show session id 74569901
Session 74569901
c2s flow:
source: 10.1.1.1 [Internal_Clients]
dst: 192.168.1.1
proto: 6
sport: 28156 dport: 80
state: DISCARD type: FLOW
src user: unknown
dst user: unknown
offload: Yes
s2c flow:
source: 192.168.1.1 [Internal_Servers]
dst: 10.1.1.1
proto: 6
sport: 80 dport: 28156
state: DISCARD type: FLOW
src user: unknown
dst user: unknown
offload: Yes
Slot : 1
DP : 2
index(local): : 7461037
start time : Wed Jul 18 09:39:00 2018
****cut for brevity****
session QoS rule : N/A (class 4)
tracker stage firewall : resource limit <<<<<<<<<<<<
tracker stage l7proc : appid bypass