[Dr.WoW] [N ° 11] ASPF

Dernière réponse dic. 05, 2019 17:50:39 152 1 0 0

Après avoir compris les stratégies de sécurité, vous pouvez penser que les stratégies de sécurité sont configurées une fois pour toutes pour vous 

protéger contre toutes les menaces. Cependant, certains protocoles changent de manière imprévisible, tels que FTP. Les paquets FTP peuvent 

outrepasser les politiques de sécurité lors de l'échange. Dans ce cas, les stratégies de sécurité ne suffisent pas pour contrôler le transfert de 

paquets et faire appel à une aide mystérieuse.


Ensuite, j'utilise FTP comme exemple pour dévoiler l'aide mystérieuse.


1 Aider les paquets de données FTP à traverser les pare-feu


Tout d'abord, j'utilise l'eNSP pour simuler un client FTP afin d'accéder à un serveur FTP, comme illustré à la figure 1-1. Le client et le serveur FTP 

se connectent directement à un pare-feu. Le client FTP réside dans la zone de confiance, tandis que le serveur FTP se trouve dans la zone non 

approuvée.


Figure 1-1 Mise en réseau d'un client FTP pour accéder à un serveur FTP


554b15403fe90.png

Comment dois-je configurer une stratégie de sécurité si je veux que le client FTP accède au serveur FTP? Vous pouvez dire: "C'est facile. Configurez une politique de sécurité pour autoriser les paquets FTP de 192.168.0.1 dans la zone de confiance à 172.16.0.1 dans la zone non approuvée."


[FW] policy interzone trust untrust outbound

[FW-policy-interzone-trust-untrust-outbound] policy 1

[FW-policy-interzone-trust-untrust-outbound-1] policy source 192.168.0.1 0

[FW-policy-interzone-trust-untrust-outbound-1] policy destination 172.16.0.1 0

[FW-policy-interzone-trust-untrust-outbound-1] policy service service-set ftp

[FW-policy-interzone-trust-untrust-outbound-1] action permit


Après la configuration, utilisez le client FTP pour accéder au serveur FTP sur le eNSP. L'accès échoue. Vérifions la configuration. Vous pouvez voir que la stratégie 1 a été mise en correspondance, indiquant que la configuration a pris effet.


[FW] display policy interzone trust untrust outbound

policy interzone trust untrust outbound

 firewall default packet-filter is deny

 policy 1 (1 times matched)

  action permit

  policy service service-set ftp (predefined)

  policy source 192.168.0.1 0

  policy destination 172.16.0.1 0

Regardons la table de session. Vous pouvez voir qu'une session a été établie sur le pare-feu.


[FW] display firewall session table

Current Total Sessions : 1

  ftp VPN:public --> public 192.168.0.1:2049-->172.16.0.1:21


Tout semble bien se passer. Eh bien, pourquoi l'accès a-t-il échoué?


Voyons les caractéristiques particulières du FTP. FTP est un protocole multi-canal typique. Le client et le serveur FTP établissent deux connexions 

entre elles, à savoir les connexions de contrôle et de données. La connexion de contrôle communique les commandes et les paramètres FTP, 

y compris les informations nécessaires à la configuration de la connexion de données. La connexion de données obtient des répertoires et 

transfère des données.


FTP fonctionne en mode actif (PORT) ou passif (PASV), déterminé par le mode de lancement de la connexion de données. En mode actif, le 

serveur FTP établit une connexion de données avec le client FTP. En mode passif, le serveur FTP reçoit la connexion de données établie par 

le client FTP.


Le mode de travail peut être défini sur le client FTP. Cet exemple utilise le mode actif, comme illustré à la figure 1-2.


Figure 1-2 Configuration du mode de travail sur le client FTP


554b1551652df.png

Regardons le processus interactif FTP en mode actif, comme illustré à la figure 1-3.


Figure 1-3 Processus interactif FTP en mode actif

554b15660caeb.png


Le processus est décrit comme suit:


1. Le client FTP utilise un port aléatoire xxxx pour lancer une demande de connexion de contrôle au port 21 du serveur FTP.


2. Le client FTP utilise la commande PORT pour négocier le numéro de port avec le serveur pour une connexion de données. Le port yyyy est obtenu.


3. Le serveur FTP lance une demande de connexion de données au port aaaa du client FTP.


4. Le serveur FTP envoie les données au client une fois la connexion de données établie.


Dans l'exemple précédent, nous avons configuré une seule stratégie de sécurité pour permettre au client FTP d'accéder au serveur FTP. 

C'est-à-dire que la connexion de contrôle a été établie. Lorsque le pare-feu a reçu le paquet du serveur FTP sur le port yyyy du client FTP, le 

pare-feu a considéré le paquet comme une nouvelle connexion, et non le paquet suivant de la connexion précédente. Pour permettre au paquet 

d'arriver au client FTP, nous devons configurer une autre politique de sécurité sur le pare-feu.


Comment résoudre ce problème? Est-ce correct si nous configurons une politique de sécurité pour les paquets du serveur FTP au client FTP? 

Mais il y a un autre problème. Le port utilisé pour la connexion de données est négocié par le client et le serveur et est donc aléatoire. Nous 

devons donc activer tous les ports, et cette opération engendre des risques de sécurité pour le client FTP. Ce serait parfait si le pare-feu pouvait 

enregistrer le port et configurer automatiquement une politique de sécurité pour permettre aux paquets de passer du serveur FTP au client FTP.


Heureusement, les concepteurs de pare-feu ont examiné ce problème et introduit le mystérieux aide Filtre de paquets spécifiques à une 

application (ASPF). Comme indiqué par le nom de la fonctionnalité, ASPF fonctionne sur les informations de la couche d'application des paquets. 

Son principe de fonctionnement consiste à vérifier les informations de la couche application des paquets et à enregistrer les données clés dans 

les informations de la couche application, afin que les paquets qui ne sont pas clairement définis pour passer dans les stratégies de sécurité 

puissent être correctement transférés.


Les entrées enregistrant les données de couche d'application clés sont appelées entrées de mappage de serveur. Une fois qu'un paquet 

correspond à une entrée de la carte du serveur, il n'est plus contrôlé par aucune politique de sécurité. Il semble activer un "canal invisible" sur 

le pare-feu. Bien sûr, ce canal n'est pas activé de manière arbitraire. Au lieu de cela, le pare-feu n'autorise l'existence d'un tel canal qu'après 

avo*****alysé les informations de la couche application des paquets afin de prédire le comportement des paquets suivants.


Quelle est la différence entre la carte du serveur et la table de session? Tout d'abord, la table de session enregistre l'état de la connexion des 

parties en communication. Après avoir généré une session pour le premier paquet d'une connexion, le pare-feu transfère directement les paquets 

suivants de la session en fonction de cette session. Les paquets ne sont plus contrôlés par des règles de sécurité. La mappe du serveur 

enregistre les informations obtenues en analysant les paquets pour les connexions existantes. Cette information indique les caractéristiques du 

paquet, selon lesquelles le pare-feu prédit le comportement du paquet.


Deuxièmement, après avoir reçu un paquet, le pare-feu vérifie si le paquet correspond à la table de session. Si tel est le cas, le pare-feu transmet 

directement le paquet. Sinon, le pare-feu vérifie si le paquet correspond à la mappe du serveur. Si le paquet correspond à la mappe du serveur, 

il n'est plus contrôlé par les stratégies de sécurité. Le pare-feu générera certainement une session pour le paquet.


La carte du serveur et la table de session sont importantes pour les pare-feu. Ils ont des fonctions différentes et ne peuvent pas se remplacer.


REMARQUE

En plus du protocole OSPF, NAT peut générer la carte du serveur, qui sera détaillée au chapitre "NAT".


Il est facile d'activer OSPF. Par exemple, activez ASPF pour FTP dans l'interzone Trust-Untrust.


REMARQUE


ASPF peut également être activé pour FTP dans une zone de sécurité.


[FW] firewall interzone trust untrust

[FW-interzone-trust-untrust] detect ftp


Ensuite, vérifions à nouveau l’accès du client FTP au serveur FTP. Exécutez la commande display firewall server-map sur le pare-feu pour afficher 

l'entrée correspondant à la carte du serveur enregistrant la connexion de données FTP.


[FW] display firewall server-map

 server-map item(s)

 ------------------------------------------------------------------------------

 ASPF, 172.16.0.1 -> 192.168.0.1:2052[any], Zone: ---

   Protocol: tcp(Appro: ftp-data), Left-Time: 00:00:57, Addr-Pool: ---

   VPN: public -> public

Nous pouvons voir que le pare-feu a généré une entrée de carte de serveur. Le paquet du serveur FTP au client FTP correspond à cette entrée et 

a été transféré. De cette manière, aucune politique de sécurité n'est requise pour ce paquet. Ce serveur-map n'existe pas de façon permanente. 

Il sera supprimé après expiration de son temps de vieillissement. Cela signifie que le "canal invisible" n'est pas activé en permanence, ce qui 

améliore la sécurité.


Affichez la table de session sur le pare-feu. Le résultat de la commande indique que le serveur FTP a établi une connexion de données avec le 

client FTP.

[FW] display firewall session table

 Current Total Sessions : 2

  ftp  VPN:public --> public 192.168.0.1:2051+->172.16.0.1:21

  ftp-data  VPN:public --> public 172.16.0.1:20-->192.168.0.1:2052


La figure 1-4 illustre le traitement ASPF pour FTP. Une fois ASPF activé, le pare-feu génère une mappe de serveur dans la connexion de contrôle 

FTP afin que la connexion de données FTP puisse être établie.


Figure 1-4 Traitement ASPF pour FTP


554b157ccfbd2.png


En conclusion, ASPF génère dynamiquement des entrées de mappage de serveur basées sur les informations de couche d'application contenues dans les paquets, simplifiant ainsi la configuration de la politique de sécurité et améliorant la sécurité. ASPF peut être considéré comme une technique de traversée de pare-feu. Les entrées de carte de serveur "ouvrent" un canal sur le pare-feu, de sorte que les paquets suivants de protocoles multi-canaux, tels que FTP, traversent le pare-feu à travers le canal sans être contrôlés par des règles de sécurité.


Outre le FTP, les pare-feu prennent en charge ASPF pour d'autres protocoles multicanaux, tels que le protocole SIP (Session Initiation Protocol), H.323 et le protocole MGCP (Media Gateway Control Protocol). Pour vérifier si un modèle de pare-feu prend en charge ASPF pour un protocole spécifique, voir la documentation produit du modèle de pare-feu.


2 Aider les paquets QQ / MSN à traverser les pare-feu

Les pare-feu prennent également en charge ASPF pour les protocoles de messagerie instantanée les plus courants, Tencent QQ et Microsoft 

Service Network (MSN) Messenger. Le processus de mise en œuvre diffère de celui de FTP. Permettez-moi de vous présenter APSF pour QQ et 

MSN.


Généralement, les messages texte QQ / MSN sont relayés par un serveur QQ ou MSN. Comme les messages audio et vidéo consomment 

beaucoup de ressources, ils ne sont pas relayés par un serveur. À la place, les parties en communication établissent une connexion pour 

transmettre de tels messages, comme illustré à la figure 1-5.


Figure 1-5 Mise en réseau pour la transmission de messages QQ / MSN


554b158c743cd.png


Dans la plupart des cas, nous configurons uniquement la stratégie de sécurité pour l'interzone Trust-Untrust sur un pare-feu afin de permettre aux 

clients QQ / MSN sur un intranet d'accéder à Internet. En raison de l'absence de stratégie de sécurité pour l'interzone Untrust-Trust, les clients 

QQ / MSN sur Internet ne peuvent pas initier de demandes de connexion audio / vidéo sur l'intranet.


QQ est utilisé à titre d'exemple. Pour permettre aux clients QQ sur Internet d'accéder au serveur QQ sur un intranet, ASPF génère l'entrée de 

mappe de serveur suivante (cette entrée est un exemple. L'entrée réelle doit contenir des informations sur la traduction d'adresse.):


Type: STUN,  ANY -> 192.168.0.1:53346,  Zone:---

 Protocol: udp(Appro: qq-derived),  Left-Time:00:05:45,  Pool: ---,

 Vpn: public -> public


Dans l'entrée, l'adresse source est ANY, indiquant que tout utilisateur peut initier des demandes de connexion vers 192.168.0.1 via le port 53346 et que le pare-feu autorise le passage des demandes. L'entrée contient l'adresse de destination (192.168.0.1), le port de destination (53346) et le type de protocole (udp), qui sont considérés comme un triplet pour les entrées de mappage de serveur.


REMARQUE


Le type d’entrée est Simple Traversal de UDP à travers des traducteurs d’adresses réseau (STUN). QQ, MSN et les entrées de mappe de serveur 

définies par l'utilisateur, décrites dans la partie suivante, sont toutes du type STUN. C'est-à-dire que les pare-feu considèrent QQ, MSN et que les 

protocoles définis par l'utilisateur sont du type STUN. STUN sera décrit dans la section "NAT ALG".


La commande permettant d'activer ASPF pour QQ et MSN est similaire à celle utilisée pour FTP. Activez ASPF pour QQ et MSN dans l'interzone Trust-Untrust.


REMARQUE


ASPF peut également être activé pour QQ et MSN dans une zone de sécurité.


[FW] firewall interzone trust untrust

[FW-interzone-trust-untrust] detect qq

[FW-interzone-trust-untrust] detect msn


3 Aider les paquets de protocole définis par l'utilisateur à traverser les pare-feu


Pour les applications dépassant le cadre d'application pris en charge de la commande detect, les pare-feu fournissent ASPF pour les protocoles 

définis par l'utilisateur. Si nous avons compris le principe de protocole d’une application, nous pouvons définir une liste de contrôle d’accès pour 

identifier les paquets de cette application. ASPF établit automatiquement une entrée triplet server-map pour l'application sur un pare-feu, afin que 

les paquets de l'application puissent passer le pare-feu. Notez que les règles ACL précises sont préférées pour minimiser l'impact négatif sur les 

autres services.

Actuellement, l'application la plus typique est le protocole TFTP (Trivial File Transfer Protocol), comme illustré à la figure 1-6.


Figure 1-6 Mise en réseau pour TFTP


554b1599b56ec.png


Les connexions de contrôle et de données TFTP partagent le numéro de port du client TFTP. Une fois que le client TFTP a lancé une demande d'accès au serveur TFTP, ASPF génère l'entrée de mappage de serveur suivante:


Type: STUN,  ANY -> 192.168.0.1:55199,  Zone:---                              

 Protocol: udp(Appro: stun-derived),  Left-Time:00:04:52,  Pool: ---,

 Vpn: public -> public


Dans cette entrée, 192.168.0.1 est l'adresse IP du client TFTP et 55199, le numéro de port activé pour le client TFTP. Le client TFTP utilise également ce numéro de port pour accéder au serveur TFTP. Avant que cette entrée de mappe de serveur n'expire, le client TFTP, à n'importe quelle adresse, peut initier des demandes de connexion vers 192.168.0.1 via le port 55199, garantissant ainsi que les paquets TFTP peuvent passer à travers le pare-feu.


De même, il n'est pas difficile d'activer ASPF pour les protocoles définis par l'utilisateur. La condition de support et la syntaxe de commande varient selon les modèles de pare-feu. Soumettez-vous à la documentation produit d'un modèle de pare-feu spécifique.

[FW] acl 3000

[FW-acl-adv-3000] rule permit ip source 192.168.0.1 0

[FW-acl-adv-3000] quit

[FW] firewall interzone trust untrust

[FW-interzone-trust-untrust] detect user-defined 3000 outbound


Pour QQ, MSN et les protocoles définis par l'utilisateur, bien que les entrées de mappage de serveur triplées générées par ASPF assurent le fonctionnement normal des services, ce mécanisme comporte des risques, car les ports ont été activés pour l'accès et les paquets correspondant aux entrées de mappage de serveur ne sont pas activés. contrôlée plus longtemps par les politiques de sécurité.


Pour réduire les risques, les pare-feu fournissent des politiques de sécurité spécifiques à ASPF (filtrage de paquets) permettant de filtrer les paquets correspondant aux entrées triplet du serveur-mappe pour un contrôle d'accès affiné. Par exemple, après la génération de l'entrée précédente de triplet server-map, configurez la liste de contrôle d'accès suivante pour autoriser uniquement les paquets correspondants de 192.168.0.1 à 172.16.0.1.


[FW] acl 3001

[FW-acl-adv-3001] rule permit ip source 192.168.0.1 0 destination 172.16.0.1 0

[FW-acl-adv-3001] quit

[FW] firewall interzone trust untrust

[FW-interzone-trust-untrust] aspf packet-filter 3001 outbound


Dans la description précédente, nous constatons que ASPF génère des entrées de mappe de serveur pour les protocoles multicanaux (tels que FTP), QQ, MSN et les protocoles définis par l'utilisateur afin d'aider les paquets de ces protocoles à traverser les pare-feu.


En outre, ASPF sur les pare-feu peut bloquer les plug-ins Java et ActiveX dans HTTP. Ces plug-ins fournis par HTTP peuvent être transformés en chevaux de Troie et en virus afin de compromettre les hôtes des réseaux intranet. En règle générale, les plug-ins Java et ActiveX sont transportés dans des charges HTTP pour la transmission. Si les pare-feu ne vérifient que les en-têtes HTTP, ils ne peuvent pas identifier les plug-ins. Dans ce cas, ASPF doit être utilisé pour vérifier les charges (payloads) HTTP afin de bloquer les plug-ins Java et ActiveX.


Il est facile de configurer un pare-feu pour bloquer les plug-ins HTTP. Exécutez les commandes de détection activex-blocking et de java-blocking dans une zone de sécurité ou un interzone. La condition de support et la syntaxe de commande varient selon les modèles de pare-feu. Soumettez-vous à la documentation produit d'un modèle de pare-feu spécifique.


  • x
  • Standard:

user_3656356
publié il y a 2019-12-5 17:50:39 Utile(0) Utile(0)
Thanks you for the information on the FTP interaction client of server
  • x
  • Standard:

Commentaire

envoyer
Connectez-vous pour répondre. Se connecter | Enregistrer

Remarque Remarque : Afin de protéger vos droits et intérêts légitimes, ceux de la communauté et des tiers, ne divulguez aucun contenu qui pourrait présenter des risques juridiques pour toutes les parties. Le contenu interdit comprend, sans toutefois s'y limiter, le contenu politiquement sensible, le contenu lié à la pornographie, aux jeux d'argent, à l'abus et au trafic de drogues, le contenu qui peut divulguer ou enfreindre la propriété intellectuelle d'autrui, y compris les secrets professionnels, les marques commerciales, les droits d'auteur et les brevets, ainsi que la vie privée personnelle. Ne partagez pas votre nom d'utilisateur ou votre mot de passe avec d'autres personnes. Toutes les opérations effectuées à partir de votre compte seront considérées comme vos propres actions, et toutes les conséquences en découlant vous seront imputées. Pour plus de détails, voir « Politique de confidentialité ».
Si le bouton de la pièce-jointe n'est pas disponible, mettez à jour Adobe Flash Player à la dernière version.
Connectez-vous pour participer à la communication et au partage

Connectez-vous pour participer à la communication et au partage

S'identifier