FortiGate: Proxy ou Flow-based inspection – Le grand dilemne ?

Essayons ici de clarifier quelques points sur ces 2 approches

Modes d’inspection

 Proxy

     L'inspection par proxy consiste à tamponner le trafic et à l'examiner en entier avant de déterminer une action. Ce tampon de l'ensemble des données à analyser permet à ce processus d'inclure davantage de données pour l'analyse que les méthodes basées sur les flux (flow) ou l'inspection DNS.
     L'avantage d'une méthode basée sur le proxy est que l'inspection peut être plus approfondie que les autres méthodes, ce qui permet de réduire le nombre de faux positifs ou des résultats négatifs dans l'analyse des données/traffic.

Flow-based

     La méthode d'inspection basée sur les flux examine le dossier lors de son passage dans le FortiGate sans aucune mise en mémoire tampon (ou presque...). À l'arrivée de chaque paquet du trafic, il est traité et transmis sans attendre la transaction complete ou la page web, etc.
     L'avantage de la méthode flow est que l'utilisateur obtient un temps de réponse pour les demandes HTTP (et un buffer) réduit, car les packets "coulent" à la vitesse ou ils arrivent.
     Les inconvénients de cette méthode sont qu'il y a une probabilité plus élevée d'un faux positif ou négatif dans l'analyse des données et qu'un nombre de points de controle ne sont pas disponibles/supportés dans la méthode d'inspection basée sur les flux. Il y a également moins d'actions disponibles au choix en fonction de la catégorisation du site web par les services FortiGuard

Avantages & inconvénients ?

J’ai pour habitude de dire, du plus indolore au plus complexe/précis

Implicit flow < Implicit proxy-based < transparent redirect to web proxy OU explicit proxy

1: Filtrage Implicit Flow

• IPv4 uniquement en profil flow-based
• Pas de blocage uniquement à la deuxiéme tentative

2: Filtrage Implicit Proxy

• IPv4 avec profil proxy-based (interception protocolaire)
• passage en CPU
• gourmand en perf
• qq petites fonctions en +; page de blocage

3a: Transparent Web Proxy

• Invisible du navigateur / client
• 2 policies dépendantes (IPv4 + redirect + web-proxy policy)
• double processing
  +++ gourmand en perf / RAM
• User-agent / RegexHost / URL Category

3b: Explicit Web Proxy

• Nécessite une configuration (qui peut etre WPAD)
• 1 policie dédiée dans web-proxy policy
• pas supporté sur toutes les machines / pas très apprécié par certaines applications (O365)
  ++ gourmand en perf / RAM
• User-agent / RegexHost / URL Category

permet le meilleur niveau de détail/sécurité (presque idem entre 3a et 3b