Que pouvons-nous faire avec les applications «inconnues»?

Qu'est-ce que l'inconnu-TCP ou inconnu-UDP qui apparaît parfois dans les journaux de trafic? En termes d'app-ID, ce sont des connexions où les données insuffisantes, ou des données qui ne correspondaient pas au comportement d'applications connues, ont été transférées et App-ID n'a pas pu identifier une application connue. Quand on voit ce type d’application à l’intérieur de l’organisation, il y a une bonne chance il s’agit de trafic bénigne : peut-être une sauvegarde homebrew ou une tâche de maintenance scriptée. Si ceux-ci s’affiche sur les sessions d’aller, ou en provenance de l’internet, ils devraient être un motif d’inquiétude.

En règle générale, la meilleure pratique est de bloquer tous les inconnus-UDP/inconnu-TCP que vous n'êtes pas sûr de ce genre de sessions, ce sont et ils pourraient être malveillants.

Bloquer aveuglément tous les trafics inconnus, cependant, peut être un peu drastique que certains d'entre eux peuvent être légitimes et peuvent être nécessaires à des fins opérationnelles. La meilleure solution est de commencer à identifier le trafic en créant des applications personnalisées, de sorte que les stratégies de sécurité peuvent être créées pour mieux contrôler les flux qui sont autorisés et ceux qui doivent être bloqués.

La façon la plus rapide d'y aller est de créer une application personnalisée simple et de définir une substitution de $ $ etAPP. Cela est utile lorsque la source et la destination sont internes et statiques, comme une connexion scriptée d'un serveur à L'autre à l'intérieur d'un environnement contrôlé:

1. Créez une application personnalisée simplifiée sans attributs ou signatures avancés.
   
   J'ai mis le facteur de risque à 5 parce que cette méthode est l'application d'Un AppID à des sessions sans autre inspection.
   
   
2. Creat une stratégie de substitution d'Application pour correspondre exactement au flux prévu (la substitution d'Application ne doit être utilisée que pour identifier les flux connus de l'administrateur).
   
3. Les sessions seront désormais identifiées car la stratégie de sécurité et d'application personnalisée peut être créée pour contrôler la session en fonction de l'application.
   

La meilleure façon d'identifier l'application consiste à configurer un packetcapture pour obtenir une bonne compréhension de ce que l'application ressemble au pare-feu, puis créer une signature pour correspondre au contenu attendu. De cette façon, vous pouvez vous assurer absolument que la session est légitime.

1. Configurez la capture de paquets et récupérez les fichiers PCAP après avoir collecté une session complète. Pour plus d'informations sur les captures de paquets, S'il vous plaît consulter son article: Getting Started: Packet Capture
   
2. Analyser la capture de paquets pour une signature appropriée.
   
   
   Pour L'exemple suivant, je vais utiliser la valeur hexadécimale de "2f69 6E66 6f3f 7478 7441 6972 506c 6179 2674 7874 5241 4F50" qui est l'équivalent en texte clair de "/info? txtAirPlay & txtRAOP" dans mon packetcapture.
   
   
3. Créez une nouvelle application personnalisée qui correspond aux paramètres de la session que vous allez identifier: dans mon exemple, J'ai capturé un protocole AirPlay personnalisé que J'ai assigné un facteur de risque de 1 car il est considéré comme sûr à l'intérieur de l'organisation.
   
   
   
   Il utilisera le port TCP 7000 comme port de destination du client au serveur.
   
   
   Dans la signature, vous pouvez utiliser la valeur hexadécimale du PCAP comme dans cet exemple: (pour les motifs Hex, assurez-vous d'ajouter un «\x» de tête et de fin pour que le moteur sache qu'il doit correspondre à l'hex et non à clair traduit)
   
   
   ou une chaîne Regex comme vu dans t son exemple: (pour les chaînes de clair, assurez-vous de commenter tous les caractères spéciaux avec une barre oblique' \ 'pour indiquer qu'il s'agit d'une correspondance littérale pour le caractère, sinon il pourrait être identifié comme un caractère générique).
   Pour limiter davantage l'emplacement de la chaîne, J'ai défini un qualificateur pour la méthode HTTP Get, car c'est là que la chaîne doit être trouvé par opposition à plus loin dans le corps. Le contexte de cette signature est le paramètre de requête http étant donné que le protocole AirPlay personnalisé utilise des commandes http pour communiquer avec le serveur, l'option de contexte doit être définie sur le protocole approprié, le cas échéant, utilisé dans la communication entre le client et Serveur.
   
   Pour plus d'exemples, consultez didacticiel vidéo: application personnalisée et mise en route: applications personnalisées et remplacement de l' application. Les contextes courants incluent'unknown-req-TCP-charge utile', 'inconnu-RSP-TCP-charge utile', 'http-req-Host-headers'et plusieurs autres où-req-représente les demandes des clients, et-RSP-sont des réponses de serveur, vous permettant de choisir de quel côté intercepter et identifier.
   
   
4. Une fois l'application personnalisée créée et la configuration validée, les sessions TCP-inconnues doivent être remplacées par la nouvelle application personnalisée dans les journaux:
5. Ce qui signifie que la politique de sécurité peut maintenant être créée pour avoir plus de contrôle sur cette application spécifique, vous permettant de bloquer le trafic inconnu sans interférer avec les applications critiques pour les entreprises:
   

J'espère que vous avez trouvé cet article instructif, sentez-vous svp libre pour laisser un commentaire.

Reaper

Pour plus d'idées et d'exemples sur les applications personnalisées S'il vous plaît visitez le Palo Alto Networks Custom signature Forum de discussion.

Voir aussi--

Mise en route : La Capture des paquets

Didacticiel vidéo: application personnalisée

Mise en route : Les applications personnalisées et app se substituent