De nombreux utilisateurs de réseaux informatiques ne connaissent généralement pas le concept de « renifleur ». Essayons de définir ce qu’est un sniffer, dans le langage simple d’un utilisateur non averti. Mais il faut d’abord se pencher sur la prédéfinition du terme lui-même.
Sniffer : qu'est-ce qu'un sniffer du point de vue de la langue anglaise et de la technologie informatique ?
En fait, il n'est pas du tout difficile de déterminer l'essence d'un tel complexe logiciel ou matériel-logiciel si vous traduisez simplement le terme.
Ce nom vient du mot anglais sniff (sniff). D'où le sens du terme russe « renifleur ». Qu'est-ce qu'un renifleur dans notre compréhension ? Un « renifleur » capable de surveiller l'utilisation du trafic réseau ou, plus simplement, un espion qui peut interférer avec le fonctionnement des réseaux locaux ou Internet, en extrayant les informations dont il a besoin en fonction de l'accès via les protocoles de transfert de données TCP/IP.
Analyseur de trafic : comment ça marche ?
Réservons tout de suite : un sniffer, qu'il s'agisse d'un composant logiciel ou shareware, est capable d'analyser et d'intercepter le trafic (données transmises et reçues) exclusivement via les cartes réseau (Ethernet). Ce qui se produit?
L'interface réseau n'est pas toujours protégée par un pare-feu (là encore, logiciel ou matériel), et donc l'interception des données transmises ou reçues devient simplement une question de technologie.
Au sein du réseau, les informations sont transmises à travers les segments. Au sein d'un segment, les paquets de données sont censés être envoyés à absolument tous les appareils connectés au réseau. Les informations segmentées sont transmises aux routeurs (routeurs), puis aux commutateurs (commutateurs) et aux concentrateurs (hubs). L'envoi d'informations s'effectue en divisant les paquets afin que l'utilisateur final reçoive toutes les parties du package connectées entre elles à partir d'itinéraires complètement différents. Ainsi, « l'écoute » de tous les itinéraires potentiels d'un abonné à un autre ou l'interaction d'une ressource Internet avec un utilisateur peut permettre non seulement d'accéder à des informations non cryptées, mais également à certaines clés secrètes, qui peuvent également être envoyées dans un tel processus d'interaction. . Et ici, l’interface réseau s’avère totalement non protégée, car un tiers intervient.
Bonnes intentions et intentions malveillantes ?
Les renifleurs peuvent être utilisés à la fois pour le meilleur et pour le pire. Sans parler de l'impact négatif, il convient de noter que ces systèmes logiciels et matériels sont assez souvent utilisés par les administrateurs système qui tentent de suivre les actions des utilisateurs non seulement sur le réseau, mais également leur comportement sur Internet en termes de ressources visitées. téléchargements activés vers des ordinateurs ou envoi à partir de ceux-ci.
La méthode par laquelle fonctionne l'analyseur de réseau est assez simple. Le renifleur détecte le trafic sortant et entrant de la machine. Nous ne parlons pas d’IP interne ou externe. Le critère le plus important est ce qu'on appelle l'adresse MAC, unique pour tout appareil connecté au Web mondial. Il permet d'identifier chaque machine du réseau.
Types de renifleurs
Mais par type, ils peuvent être divisés en plusieurs principaux :
- matériel;
- logiciel;
- matériel et logiciel;
- applets en ligne.
Détection comportementale de la présence d'un sniffer sur le réseau
Vous pouvez détecter le même renifleur WiFi par la charge sur le réseau. S'il est clair que le transfert de données ou la connexion n'est pas au niveau indiqué par le fournisseur (ou que le routeur le permet), vous devez immédiatement y prêter attention.
D'un autre côté, le fournisseur peut également exécuter un logiciel de détection pour surveiller le trafic à l'insu de l'utilisateur. Mais, en règle générale, l’utilisateur n’en est même pas au courant. Mais l'organisme fournissant les services de communication et de connexion Internet garantit ainsi à l'utilisateur une sécurité totale en termes d'interception des inondations, d'auto-installation des clients de divers chevaux de Troie, espions, etc. Mais de tels outils sont plutôt logiciels et n'ont pas beaucoup d'impact sur le réseau ou les terminaux des utilisateurs.
Ressources en ligne
Mais un analyseur de trafic en ligne peut être particulièrement dangereux. Un système de piratage informatique primitif repose sur l’utilisation de renifleurs. La technologie dans sa forme la plus simple se résume au fait qu'au départ, l'attaquant s'inscrit sur une certaine ressource, puis télécharge une image sur le site. Après confirmation du téléchargement, un lien vers un renifleur en ligne est émis, qui est envoyé à une victime potentielle, par exemple, sous la forme d'un e-mail ou du même message SMS avec un texte du type « Vous avez reçu une félicitation de tel-et -donc. Pour ouvrir la photo (carte postale), cliquez sur le lien.
Les utilisateurs naïfs cliquent sur le lien hypertexte spécifié, ce qui active la reconnaissance et transmet l'adresse IP externe à l'attaquant. S'il dispose de l'application appropriée, il pourra non seulement visualiser toutes les données stockées sur l'ordinateur, mais également modifier facilement les paramètres du système de l'extérieur, ce dont l'utilisateur local ne se rendra même pas compte, prenant un tel changement pour le influence d'un virus. Mais le scanner ne montrera aucune menace lors de la vérification.
Comment se protéger de l’interception de données ?
Qu'il s'agisse d'un renifleur WiFi ou de tout autre analyseur, il existe toujours des systèmes de protection contre l'analyse non autorisée du trafic. Il n'y a qu'une seule condition : ils ne doivent être installés que si vous êtes totalement confiant dans les « écoutes téléphoniques ».
De tels outils logiciels sont le plus souvent appelés « antisniffers ». Mais si vous y réfléchissez bien, ce sont les mêmes renifleurs qui analysent le trafic, mais bloquent les autres programmes essayant de recevoir
D’où la question légitime : est-ce que cela vaut la peine d’installer un tel logiciel ? Peut-être que son piratage par des pirates informatiques causera encore plus de dégâts, ou bloquera-t-il lui-même ce qui devrait fonctionner ?
Dans le cas le plus simple des systèmes Windows, il est préférable d'utiliser le pare-feu intégré comme protection. Parfois, il peut y avoir des conflits avec l'antivirus installé, mais cela ne s'applique souvent qu'aux packages gratuits. Les versions professionnelles achetées ou activées mensuellement ne présentent pas de tels défauts.
Au lieu d'une postface
Tout dépend du concept de « renifleur ». Je pense que beaucoup de gens ont déjà compris ce qu'est un renifleur. Enfin, la question demeure : dans quelle mesure l’utilisateur moyen utilisera-t-il correctement de telles choses ? Sinon, chez les jeunes utilisateurs, on peut parfois remarquer une tendance au hooliganisme informatique. Ils pensent que pirater l'ordinateur de quelqu'un d'autre est quelque chose comme une compétition intéressante ou une affirmation de soi. Malheureusement, aucun d'entre eux ne pense même aux conséquences, mais il est très facile d'identifier un attaquant utilisant le même sniffer en ligne grâce à son adresse IP externe, par exemple sur le site WhoIs. Certes, l'emplacement du fournisseur sera indiqué comme emplacement, cependant, le pays et la ville seront déterminés avec précision. Eh bien, il s’agit de petites choses : soit un appel au fournisseur pour bloquer le terminal à partir duquel un accès non autorisé a été effectué, soit une affaire pénale. Tirez vos propres conclusions.
Si un programme est installé pour déterminer l'emplacement du terminal à partir duquel une tentative d'accès est effectuée, la situation est encore plus simple. Mais les conséquences peuvent être catastrophiques, car tous les utilisateurs n’utilisent pas ces anonymiseurs ou ces serveurs proxy virtuels et n’ont même aucune idée d’Internet. Cela vaudrait la peine d'apprendre...
Reniflage intelligent vous permet d'intercepter le trafic réseau et d'afficher son contenu en ASCII. Le programme capture les paquets passant par la carte réseau et affiche le contenu des paquets sous forme de texte (protocoles http, pop3, smtp, ftp) et sous forme de vidage hexadécimal. Pour capturer les paquets TCP/IP, SmartSniff utilise les techniques suivantes : raw sockets - RAW Sockets, WinCap Capture Driver et Microsoft Network Monitor Driver. Le programme prend en charge la langue russe et est facile à utiliser.
Programme Sniffer pour capturer des paquets
 |
SmartSniff affiche les informations suivantes : nom du protocole, adresse locale et distante, port local et distant, nœud local, nom du service, volume de données, taille totale, heure de capture et heure du dernier paquet, durée, adresse MAC locale et distante, pays et paquet de données. Contenu . Le programme a des paramètres flexibles, il implémente la fonction d'un filtre de capture, décompressant les réponses http, convertissant les adresses IP, l'utilitaire est minimisé dans la barre d'état système. SmartSniff génère un rapport sur les flux de paquets sous forme de page HTML. Le programme peut exporter des flux TCP/IP.
Régime général
La séquence d'étapes qu'un programme utilisant la bibliothèque pcap (de PacketCAPture) doit effectuer pour terminer sa tâche est la suivante :
- Définissez l'interface réseau qui sera écoutée. (Sous Linux, cela pourrait être eth0, sous BSD xl1).
- Initialisez pcap. Dans ce cas, la bibliothèque est informée sur quelle interface nous écouterons les données. Il est possible d'écouter plusieurs interfaces simultanément (dans des sessions différentes).
- S'il est nécessaire de créer un filtre (par exemple, nous ne nous intéressons qu'aux paquets TCP arrivant sur le port 23), « compilez » ce filtre et appliquez-le à une session particulière.
- Accédez au cycle de réception des paquets. Après cela, chaque fois qu'un autre paquet arrive et passe à travers le filtre spécifié, une fonction est appelée et doit être définie à l'avance. Cette fonction peut effectuer n'importe quelle action que nous voulons. Il peut analyser le package et le donner à l'utilisateur, il peut le sauvegarder sur le disque ou il ne peut rien faire du tout.
- Une fois terminé, vous devez fermer toutes les sessions ouvertes.
Examinons les étapes répertoriées en détail.
Définition de l'interface
Pour déterminer l’interface sur laquelle écouter, vous pouvez utiliser deux méthodes.
La première est que le nom de l'interface est spécifié par l'utilisateur. Considérons le programme suivant :
#inclure
L'utilisateur spécifie l'interface en passant son nom comme premier argument à notre programme. Naturellement, l'interface spécifiée par l'utilisateur doit exister.
La deuxième façon consiste à connaître le nom de l'interface à partir de la bibliothèque elle-même :
#inclure
Dans ce cas, pcap nous donne le nom de l’interface dont il est propriétaire. La ligne errbuf contiendra une description de l'erreur si celle-ci se produit lors de l'exécution de l'appel pcap_lookupdev().
Ouverture d'une interface pour l'interception de paquets
Pour créer une session d'interception de trafic, vous devez appeler la fonction pcap_open_live(). Le prototype de cette fonction (extrait de la page de manuel pcap) ressemble à ceci :
Pcap_t *pcap_open_live (char *device, int snaplen, int promisc, int to_ms, char *ebuf)
Le premier argument est le nom du périphérique que nous avons défini à l'étape précédente. snaplen est un entier spécifiant le nombre maximum d'octets d'une trame réseau qui seront capturés par la bibliothèque. Si promisc est défini sur true, l'interface passe en mode dit promiscuous (les paquets adressés aux autres stations du réseau sont interceptés). to_ms - délai d'attente en millisecondes (si la valeur est définie sur zéro, la lecture aura lieu jusqu'à la première erreur, si elle est définie sur moins un - infiniment). Enfin, errbuf est la ligne où nous recevrons le message d'erreur. La fonction renvoie le handle de session (descripteur).
Pour démontrer, regardons un morceau de code :
#inclure
Ici, une interface est ouverte dont le nom est indiqué dans la ligne somedev , indiquant le nombre d'octets du paquet à capturer (la valeur BUFSIZ est définie dans pcap.h). L'interface réseau passe en mode promiscuité. Les données seront lues jusqu'à ce qu'une erreur se produise. En cas d'erreur, vous pouvez afficher sa description textuelle à l'écran à l'aide du pointeur errbuf.
Une remarque sur l'interception du trafic en modes promiscuité et non promiscuité : les deux méthodes sont très différentes. Dans le cas d'une interception de trafic en mode non promiscuité, le nœud reçoit uniquement le trafic qui lui est dirigé ou qui lui est lié. Seul le trafic vers, depuis et acheminé via l'hôte sera intercepté par notre programme. En mode promiscuité, l'interface réseau accepte tous les paquets transitant par le câble. Dans un environnement non commuté, cela peut concerner tout le trafic réseau. Son avantage évident est qu'il fournit un plus grand nombre de paquets à capturer, ce qui peut (ou non) être utile en fonction de la raison pour laquelle vous capturez le flux réseau.
Cependant, une interception de trafic en mode promiscuité peut être détectée ; un autre nœud peut déterminer avec une grande précision si nous utilisons le mode promiscuité. De plus, il ne fonctionne que dans des environnements non commutés (tels que des hubs ou des commutateurs inondés de paquets arp). Troisièmement, si le réseau est fortement chargé, notre programme utilisera une grande quantité de ressources système.
Filtrage du trafic
Souvent, un intercepteur de paquets est nécessaire pour intercepter non pas tous, mais seulement certains paquets. Par exemple, il arrive parfois que nous souhaitions intercepter le trafic sur le port 23 (telnet) à la recherche de mots de passe. Ou peut-être souhaitons-nous intercepter un fichier envoyé via le port 21 (FTP). Peut-être souhaitons-nous uniquement intercepter le trafic DNS (port UDP 53). Quoi qu’il en soit, il est très rarement nécessaire d’intercepter toutes les données. Les fonctions pcap_compile() et pcap_setfilter() sont utilisées pour filtrer le trafic.
Une fois que nous avons appelé pcap_open_live() et que nous avons une session de capture de trafic fonctionnelle, nous pouvons appliquer notre filtre. Naturellement, vous pouvez implémenter le filtre manuellement en analysant les en-têtes ETH/IP/TCP après avoir reçu le paquet, mais l'utilisation du filtre pcap interne est plus efficace et également plus simple.
Avant de pouvoir appliquer un filtre, vous devez le « compiler ». L'expression de filtre est stockée dans une chaîne ordinaire (tableau de caractères). La syntaxe de ces expressions est décrite en détail dans la page de manuel tcpdump (man tcpdump).
La fonction pcap_compile() est utilisée pour compiler le filtre. Son prototype ressemble à ceci :
Int pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimiser, masque de réseau bpf_u_int32)
Le premier argument est le handle (descripteur) de notre session (pcap_t *handle dans l'exemple précédent). L'argument suivant est un pointeur vers la zone en mémoire où nous stockerons la version compilée de notre filtre. Vient ensuite l’expression de filtre elle-même sous la forme d’une chaîne régulière. Le paramètre suivant détermine si notre expression doit être optimisée ou non (comme d'habitude, 0 signifie non, 1 signifie oui). Le dernier paramètre est le masque de réseau auquel notre filtre est appliqué. La fonction renvoie -1 en cas d'erreur, toutes les autres valeurs indiquent une réussite.
Une fois l'expression compilée, il faut l'appliquer, ce qui se fait à l'aide de la fonction pcap_setfilter(). Son prototype est le suivant :
Int pcap_setfilter(pcap_t *p, struct bpf_program *fp)
Le premier argument est le handle (descripteur) de notre session d'interception de paquets, le second est un pointeur vers la version compilée de l'expression du filtre (généralement le deuxième argument de la fonction pcap_compile()).
L'exemple suivant illustre l'utilisation d'un filtre :
#inclure
Ce programme prépare un intercepteur pour les paquets allant vers ou depuis le port 23, en mode promiscuité, sur l'interface eth0. L'exemple contient la fonction pcap_lookupnet(), qui renvoie l'adresse réseau et le masque de réseau du périphérique dont le nom lui est transmis en paramètre. Son utilisation est nécessaire car pour appliquer un filtre, il faut connaître l'adresse et le masque réseau.
Interception de paquets
Il existe deux techniques d'interception de paquets. Vous pouvez intercepter et traiter un paquet à la fois, ou vous pouvez travailler avec un groupe de paquets en définissant une boucle spéciale qui s'exécutera jusqu'à ce que pcap intercepte un nombre spécifié de paquets. Pour travailler dans le premier mode, la fonction pcap_next() est utilisée. Prototype pcap_next() :
U_char *pcap_next(pcap_t *p, struct pcap_pkthdr *h)
Le premier argument est le handle de notre session, le second est un pointeur vers une structure dans laquelle les informations sur le paquet seront stockées, telles que l'heure à laquelle il a été intercepté, la longueur du paquet et la longueur de sa partie individuelle ( par exemple, si le paquet est fragmenté). pcap_next() renvoie un pointeur u_char vers l'emplacement mémoire où est stocké le paquet décrit par cette structure.
Démonstration de l'utilisation de pcap_next() pour capturer un seul paquet :
#inclure
Ce programme intercepte les paquets sur le périphérique renvoyés par pcap_lookupdev(), le mettant en mode pormiscuous. Il détecte un paquet arrivant via le port 23 (telnet) et affiche sa taille en octets. L'appel de pcap_close() ferme une session de capture ouverte.
La méthode alternative, bien que plus difficile à comprendre, sera probablement plus utile. Il existe très peu (voire aucune) de captures de paquets qui utilisent pcap_next() . Dans la grande majorité des cas, ils utilisent pcap_loop() ou pcap_dispatch() (qui à son tour utilise pcap_loop()). Afin de comprendre l'utilisation de ces deux fonctions, vous devez comprendre l'idée des fonctions de rappel.
Les fonctions de rappel sont une technique de programmation fréquemment utilisée. Le principe est assez simple. Disons que vous avez un programme qui attend un événement. Dans le but, par exemple, de traiter une frappe au clavier. Chaque fois qu'une touche est enfoncée, je souhaite appeler une fonction qui gérera cet événement. La fonction que j'utilise est une fonction de rappel. Chaque fois que l'utilisateur appuie sur une touche, mon programme appellera une fonction de rappel. Les fonctions de rappel sont utilisées dans pcap, mais au lieu de les appeler lorsque l'utilisateur appuie sur une touche, pcap les appelle lorsqu'il reçoit un autre paquet. pcap_loop() et pcap_dispatch() sont des fonctions qui utilisent le mécanisme de fonction de rappel presque de la même manière. Les deux appellent une fonction de rappel à chaque fois que pcap intercepte un paquet qui passe à travers le filtre (à moins bien sûr que le filtre soit compilé et appliqué à la session, sinon tous les paquets interceptés sont transmis à la fonction de rappel)
Prototype de fonction pcap_loop() :
Int pcap_loop (pcap_t *p, int cnt, rappel pcap_handler, u_char *user);
Le premier argument est notre handle de session. L'entier suivant indique à pcap_loop() le nombre total de paquets à capturer (une valeur négative signifie que les paquets doivent être capturés jusqu'à ce qu'une erreur se produise). Le troisième argument est le nom de la fonction de rappel (nom uniquement, sans parenthèses). Le dernier argument est utilisé dans certaines applications, mais il est généralement simplement défini sur NULL. pcap_dispatch() est presque identique, la seule différence est la façon dont les fonctions gèrent le délai d'attente, dont la valeur est définie lorsque pcap_open_live() est appelé. pcap_loop() ignore simplement les délais d'attente, contrairement à pcap_dispatch() . Les détails sont dans man pcap.
Avant de donner un exemple d'utilisation de pcap_loop(), nous devons examiner le format de notre fonction de rappel. Nous ne pouvons pas définir arbitrairement un prototype de fonction de rappel car pcap_loop() ne saura pas quoi en faire. Le prototype de notre fonction de rappel devrait ressembler à ceci :
Void got_packet (u_char *args, const struct pcap_pkthdr *en-tête, const u_char *packet) ;
Regardons-le de plus près. Tout d'abord, la fonction renvoie une valeur vide (void). Cela est logique puisque pcap_loop() ne peut pas savoir quoi faire avec la valeur de retour. Le premier argument est le même que le dernier argument de pcap_loop(). Quelle que soit la valeur utilisée comme dernier argument de pcap_loop(), elle est transmise comme premier argument à la fonction de rappel chaque fois qu'elle est appelée depuis pcap_loop() . Le deuxième argument est l'en-tête pcap, qui contient des informations sur le moment où le paquet a été capturé, sa taille, etc. La structure pcap_pkthdr est définie dans pcap.h comme suit :
Struct pcap_pkthdr ( struct timeval ts; // timestamp bpf_u_int32 caplen; // longueur de la partie capturée du paquet bpf_u_int32 len; // longueur totale du paquet );
Le dernier argument de la fonction de rappel est le plus intéressant. Il s'agit d'un pointeur vers un tampon, qui contient en fait l'intégralité du paquet capturé à l'aide de pcap_loop().
Comment utiliser la variable packet ? Le paquet contient de nombreux attributs, donc comme vous pouvez l'imaginer, ce n'est pas réellement une chaîne, mais un ensemble de structures (par exemple, un paquet TCP/IP contiendra un en-tête Ethernet, IP, TCP et les données elles-mêmes). Le paramètre packet, qui est de type u_char , est en fait une version sérialisée de ces structures. Afin d'obtenir des données utiles à partir de ces structures, nous devons effectuer quelques transformations.
Tout d'abord, nous devons avoir des structures définies dans le programme que nous utiliserons. Nous utiliserons les structures suivantes (nous pourrions en fait les extraire directement des fichiers d'en-tête, mais les noms de champs des structures varient d'une plateforme à l'autre, ils sont donc utilisés à des fins de démonstration) :
Struct sniff_ethernet ( u_char ether_dhost; u_char ether_shost; u_short ether_type; /* IP? ARP? RARP? etc */ ); // Structure d'en-tête IP sniff_ip ( #if BYTE_ORDER == LITTLE_ENDIAN u_int ip_hl:4, ip_v:4; #endif #if BYTE_ORDER == BIG_ENDIAN u_int ip_v:4, /* version */ ip_hl:4; /* longueur de l'en-tête */ #endif /* pas _IP_VHL */ u_char ip_tos; u_short ip_len; u_short ip_id; u_short ip_off; #define IP_RF 0x8000 /* indicateur de fragment réservé */ #define IP_DF 0x4000 /* dont fragment flag */ #define IP_MF 0x2000 /* plus de fragments flag */ #define IP_OFFMASK 0x1fff /* masque pour fragmenter les bits */ u_char ip_ttl; /* durée de vie */ u_char ip_p; /* protocole */ u_short ip_sum; /* somme de contrôle */ struct in_addr ip_src,ip_dst; /* source et adresse de destination */ ); struct sniff_tcp ( u_short th_sport; u_short th_dport; tcp_seq th_seq; /* numéro de séquence */ tcp_seq th_ack; /* numéro d'accusé de réception */ #if BYTE_ORDER == LITTLE_ENDIAN u_int th_x2:4, /* (inutilisé) */ th_off:4; / * décalage de données */ #endif #if BYTE_ORDER == BIG_ENDIAN u_int th_off:4, /* décalage de données */ th_x2:4; /* (inutilisé) */ #endif u_char th_flags; #define TH_FIN 0x01 #define TH_SYN 0x02 #define TH_RST 0x04 #define th_push 0x08 #define th_ack 0x10 #define th_urg 0x20 #define th_ece 0x40 #define th_cwr 0x80 #define th_flags \ (th_fin | th_syn | th_rst | \ th_ack | th_urg | / u_short th_sum; /* somme de contrôle */ u_short th_urp; /* pointeur urgent */ );
Si des descriptions de structure à partir de fichiers d'en-tête standard sont utilisées, alors parfois pour qu'un programme qui utilise une description d'en-tête TCP puisse compiler sans erreurs, il est nécessaire de définir le symbole _BSD_SOURCE avant d'inclure les fichiers d'en-tête. Une autre méthode consiste à définir manuellement les structures qui décrivent l’en-tête TCP.
pcap utilise naturellement exactement les mêmes structures lors de la capture de paquets. Ensuite, il crée simplement une chaîne u_char (tampon) et y copie les données des structures. Comment réanalyser une chaîne en structures ? Cela se fait facilement à l’aide de pointeurs et de conversions de types.
Tout d'abord, déclarons les variables dont nous avons besoin pour analyser le package u_char dans des en-têtes distincts :
Const struct sniff_ethernet *ethernet; const struct sniff_ip *ip; const struct sniff_tcp *tcp; const char *charge utile ; int size_ethernet = sizeof(struct sniff_ethernet); int size_ip = sizeof(struct sniff_ip); int size_tcp = sizeof(struct sniff_tcp);
Maintenant, nous effectuons la conversion de type :
Ethernet = (struct sniff_ethernet*)(paquet); ip = (struct sniff_ip*)(paquet + size_ethernet); tcp = (struct sniff_tcp*)(paquet + size_ethernet + size_ip); charge utile = (u_char *)(paquet + size_ethernet + size_ip + size_tcp);
Après cela, nous pouvons accéder aux champs de toutes les structures de la manière habituelle, par exemple :
Si (tcp->th_flags & TH_URG) ( ... ); ... printf("TTL = %d\n", ip->ip_ttl);
Fermer
Lorsque vous avez terminé, vous devez fermer la session. Cela se fait à l'aide de la fonction pcap_close().
Les analyseurs de paquets réseau, ou renifleurs, ont été initialement développés pour résoudre les problèmes de réseau. Ils sont capables d'intercepter, d'interpréter et de stocker les paquets transmis sur le réseau pour une analyse ultérieure. D'une part, cela permet aux administrateurs système et aux ingénieurs du support technique d'observer comment les données sont transférées sur le réseau, de diagnostiquer et de résoudre les problèmes qui surviennent. En ce sens, les renifleurs de paquets constituent un outil puissant pour diagnostiquer les problèmes de réseau. D'un autre côté, comme de nombreux autres outils puissants initialement destinés à l'administration, les renifleurs ont progressivement commencé à être utilisés à des fins complètement différentes. En effet, un sniffer entre les mains d'un attaquant est un outil plutôt dangereux et peut être utilisé pour obtenir des mots de passe et d'autres informations confidentielles. Cependant, il ne faut pas penser que les renifleurs sont une sorte d'outil magique grâce auquel tout pirate informatique peut facilement visualiser les informations confidentielles transmises sur le réseau. Et avant de prouver que le danger posé par les renifleurs n'est pas aussi grand qu'on le prétend souvent, examinons plus en détail les principes de leur fonctionnement.
Principes de fonctionnement des renifleurs de paquets
Plus loin dans cet article, nous considérerons uniquement les renifleurs de logiciels conçus pour les réseaux Ethernet. Un renifleur est un programme qui fonctionne au niveau de la carte réseau NIC (Network Interface Card) (couche liaison) et intercepte secrètement tout le trafic. Étant donné que les renifleurs opèrent au niveau de la couche liaison de données du modèle OSI, ils n'ont pas à respecter les règles des protocoles de couche supérieure. Les renifleurs contournent les mécanismes de filtrage (adresses, ports, etc.) que les pilotes Ethernet et la pile TCP/IP utilisent pour interpréter les données. Les renifleurs de paquets captent du fil tout ce qui le traverse. Les renifleurs peuvent stocker des images au format binaire, puis les décrypter pour révéler des informations de niveau supérieur cachées à l'intérieur (Figure 1).
Pour que le renifleur capture tous les paquets passant par la carte réseau, le pilote de la carte réseau doit prendre en charge le mode promiscuité. C'est dans ce mode de fonctionnement de la carte réseau que le renifleur est capable d'intercepter tous les paquets. Ce mode de fonctionnement de la carte réseau est automatiquement activé au lancement du renifleur ou est défini manuellement par les paramètres du renifleur correspondant.
Tout le trafic intercepté est transmis à un décodeur de paquets, qui identifie et divise les paquets selon les niveaux hiérarchiques appropriés. En fonction des capacités d'un renifleur particulier, les informations sur les paquets fournies peuvent ensuite être analysées et filtrées davantage.
Limites de l'utilisation des renifleurs
Les renifleurs représentaient le plus grand danger à l'époque où les informations étaient transmises sur le réseau en texte clair (sans cryptage) et où les réseaux locaux étaient construits sur la base de concentrateurs (hubs). Cependant, cette époque est définitivement révolue et aujourd’hui, utiliser des renifleurs pour accéder à des informations confidentielles n’est en aucun cas une tâche facile.
Le fait est que lors de la construction de réseaux locaux basés sur des hubs, il existe un certain support de transmission de données commun (câble réseau) et tous les nœuds du réseau échangent des paquets, en compétition pour l'accès à ce support (Fig. 2), et un paquet envoyé par un réseau Le nœud est transmis à tous les ports du hub et ce paquet est écouté par tous les autres nœuds du réseau, mais seul le nœud auquel il est adressé le reçoit. De plus, si un renifleur de paquets est installé sur l'un des nœuds du réseau, il peut alors intercepter tous les paquets réseau liés à un segment de réseau donné (le réseau formé par le hub).
Les commutateurs sont des appareils plus intelligents que les hubs de diffusion et isolent le trafic réseau. Le commutateur connaît les adresses des appareils connectés à chaque port et transmet les paquets uniquement entre les ports nécessaires. Cela vous permet de décharger d'autres ports sans avoir à leur transmettre chaque paquet, comme le fait un hub. Ainsi, un paquet envoyé par un certain nœud du réseau est transmis uniquement au port de commutation auquel le destinataire du paquet est connecté, et tous les autres nœuds du réseau ne sont pas en mesure de détecter ce paquet (Fig. 3).
Par conséquent, si le réseau est construit sur la base d'un commutateur, un renifleur installé sur l'un des ordinateurs du réseau est capable d'intercepter uniquement les paquets échangés entre cet ordinateur et d'autres nœuds du réseau. De ce fait, afin de pouvoir intercepter les paquets que l'ordinateur ou le serveur qui intéresse l'attaquant échange avec d'autres nœuds du réseau, il est nécessaire d'installer un renifleur sur cet ordinateur (serveur) particulier, ce qui n'est en réalité pas si simple. Cependant, vous devez garder à l'esprit que certains renifleurs de paquets sont lancés à partir de la ligne de commande et peuvent ne pas avoir d'interface graphique. De tels renifleurs, en principe, peuvent être installés et lancés à distance sans que l'utilisateur ne le remarque.
De plus, vous devez également garder à l’esprit que même si les commutateurs isolent le trafic réseau, tous les commutateurs gérés disposent d’une fonctionnalité de redirection de port ou de mise en miroir de ports. Autrement dit, le port du commutateur peut être configuré de manière à ce que tous les paquets arrivant sur d'autres ports du commutateur y soient dupliqués. Si, dans ce cas, un ordinateur équipé d'un renifleur de paquets est connecté à un tel port, il peut alors intercepter tous les paquets échangés entre les ordinateurs sur un segment de réseau donné. Cependant, en règle générale, la possibilité de configurer le commutateur n'est disponible que pour l'administrateur réseau. Bien entendu, cela ne signifie pas qu'il ne peut pas être un attaquant, mais l'administrateur réseau dispose de nombreux autres moyens de contrôler tous les utilisateurs du réseau local, et il est peu probable qu'il vous surveille de manière aussi sophistiquée.
Une autre raison pour laquelle les renifleurs ne sont plus aussi dangereux qu’avant est que la plupart des données sensibles sont désormais transmises cryptées. Les services ouverts et non cryptés disparaissent rapidement d’Internet. Par exemple, lors de la visite de sites Web, le protocole SSL (Secure Sockets Layer) est de plus en plus utilisé ; SFTP (Secure FTP) est utilisé à la place du FTP ouvert, et les réseaux privés virtuels (VPN) sont de plus en plus utilisés pour d'autres services qui n'utilisent pas le cryptage par défaut.
Ainsi, ceux qui s’inquiètent du potentiel d’utilisation malveillante des renifleurs de paquets doivent garder ce qui suit à l’esprit. Premièrement, pour constituer une menace sérieuse pour votre réseau, les renifleurs doivent être situés au sein même du réseau. Deuxièmement, les normes de chiffrement actuelles rendent extrêmement difficile l'interception d'informations sensibles. Par conséquent, à l'heure actuelle, les renifleurs de paquets perdent progressivement leur pertinence en tant qu'outils de piratage, mais ils restent en même temps un outil efficace et puissant pour diagnostiquer les réseaux. De plus, les renifleurs peuvent être utilisés avec succès non seulement pour diagnostiquer et localiser les problèmes de réseau, mais également pour auditer la sécurité du réseau. En particulier, l'utilisation d'analyseurs de paquets permet de détecter le trafic non autorisé, de détecter et d'identifier les logiciels non autorisés, d'identifier les protocoles inutilisés pour les supprimer du réseau, de générer du trafic pour les tests d'intrusion (test d'intrusion) afin de vérifier le système de sécurité, de travailler avec systèmes de détection d'intrusion (Intrusion Detection System (IDS).
Présentation des renifleurs de paquets logiciels
Tous les renifleurs de logiciels peuvent être divisés en deux catégories : les renifleurs prenant en charge le lancement à partir de la ligne de commande et les renifleurs dotés d'une interface graphique. Cependant, notons qu’il existe des renifleurs qui combinent ces deux capacités. De plus, les renifleurs diffèrent les uns des autres par les protocoles qu'ils prennent en charge, la profondeur de l'analyse des paquets interceptés, la possibilité de configurer des filtres et la possibilité de compatibilité avec d'autres programmes.
En règle générale, la fenêtre de tout renifleur doté d'une interface graphique se compose de trois zones. Le premier d'entre eux affiche les données récapitulatives des paquets interceptés. Typiquement, cette zone affiche un minimum de champs, à savoir : l'heure d'interception des paquets ; Adresses IP de l'expéditeur et du destinataire du paquet ; Adresses MAC de l'expéditeur et du destinataire du paquet, adresses des ports source et destination ; type de protocole (couche réseau, transport ou application) ; quelques informations récapitulatives sur les données interceptées. La deuxième zone affiche des informations statistiques sur le package individuel sélectionné, et enfin la troisième zone affiche le package sous forme de caractères hexadécimaux ou ASCII.
Presque tous les renifleurs de paquets vous permettent d'analyser les paquets décodés (c'est pourquoi les renifleurs de paquets sont également appelés analyseurs de paquets ou analyseurs de protocole). Le renifleur distribue les paquets interceptés entre les couches et les protocoles. Certains renifleurs de paquets sont capables de reconnaître le protocole et d'afficher les informations capturées. Ce type d'informations est généralement affiché dans la deuxième zone de la fenêtre du renifleur. Par exemple, n'importe quel renifleur peut reconnaître le protocole TCP, et les renifleurs avancés peuvent déterminer quelle application a généré ce trafic. La plupart des analyseurs de protocoles reconnaissent plus de 500 protocoles différents et peuvent les décrire et les décoder par leur nom. Plus un renifleur peut décoder et afficher d’informations à l’écran, moins il devra être décodé manuellement.
Un problème que les renifleurs de paquets peuvent rencontrer est l'incapacité d'identifier correctement un protocole utilisant un port autre que le port par défaut. Par exemple, pour améliorer la sécurité, certaines applications connues peuvent être configurées pour utiliser des ports autres que les ports par défaut. Ainsi, au lieu du traditionnel port 80, réservé au serveur web, ce serveur peut être reconfiguré de force sur le port 8088 ou tout autre. Dans cette situation, certains analyseurs de paquets ne sont pas capables de déterminer correctement le protocole et d'afficher uniquement des informations sur le protocole de niveau inférieur (TCP ou UDP).
Il existe des renifleurs de logiciels fournis avec des modules d'analyse logiciels sous forme de plugins ou de modules intégrés qui vous permettent de créer des rapports contenant des informations analytiques utiles sur le trafic intercepté.
Une autre caractéristique de la plupart des logiciels d'analyse de paquets est la possibilité de configurer des filtres avant et après la capture du trafic. Les filtres sélectionnent certains paquets du trafic général selon un critère donné, ce qui permet de s'affranchir des informations inutiles lors de l'analyse du trafic.
Wireshark est un puissant analyseur de réseau qui peut être utilisé pour analyser le trafic transitant par l'interface réseau de votre ordinateur. Vous en aurez peut-être besoin pour détecter et résoudre des problèmes de réseau, déboguer vos applications Web, programmes réseau ou sites. Wireshark vous permet de visualiser entièrement le contenu d'un paquet à tous les niveaux, afin que vous puissiez mieux comprendre le fonctionnement du réseau à bas niveau.
Tous les paquets sont capturés en temps réel et fournis dans un format facile à lire. Le programme prend en charge un système de filtrage très puissant, une mise en évidence des couleurs et d'autres fonctionnalités qui vous aideront à trouver les bons packages. Dans ce didacticiel, nous verrons comment utiliser Wireshark pour analyser le trafic. Récemment, les développeurs ont commencé à travailler sur la deuxième branche du programme Wireshark 2.0, de nombreux changements et améliorations y ont été apportés, notamment pour l'interface. C'est ce que nous utiliserons dans cet article.
Avant de passer à l'examen des moyens d'analyser le trafic, vous devez examiner plus en détail les fonctionnalités prises en charge par le programme, les protocoles avec lesquels il peut fonctionner et ce qu'il peut faire. Voici les principales caractéristiques du programme :
- Capturez des paquets en temps réel à partir d'interfaces réseau filaires ou de tout autre type, ainsi que lisez à partir d'un fichier ;
- Les interfaces de capture suivantes sont prises en charge : Ethernet, IEEE 802.11, PPP et interfaces virtuelles locales ;
- Les paquets peuvent être filtrés en fonction de nombreux paramètres à l'aide de filtres ;
- Tous les protocoles connus sont mis en évidence dans la liste dans différentes couleurs, par exemple TCP, HTTP, FTP, DNS, ICMP, etc. ;
- Prise en charge de la capture du trafic d'appels VoIP ;
- Le décryptage du trafic HTTPS est pris en charge si un certificat est disponible ;
- Décryptage du trafic WEP et WPA des réseaux sans fil avec une clé et une poignée de main ;
- Affichage des statistiques de charge du réseau ;
- Afficher le contenu du package pour toutes les couches réseau ;
- Affiche l'heure d'envoi et de réception des colis.
Le programme possède de nombreuses autres fonctionnalités, mais ce sont les principales qui pourraient vous intéresser.
Comment utiliser Wireshark
Je suppose que le programme est déjà installé, mais sinon, vous pouvez l'installer à partir des référentiels officiels. Pour ce faire, tapez la commande dans Ubuntu :
sudo apt installer Wireshark
Après l'installation, vous pouvez retrouver le programme dans le menu principal de la distribution. Vous devez exécuter Wireshark avec les droits de superutilisateur, sinon il ne pourra pas analyser les paquets réseau. Cela peut être fait depuis le menu principal ou via le terminal en utilisant la commande pour KDE :
Et pour Gnome/Unity :
La fenêtre principale du programme est divisée en trois parties : la première colonne contient une liste des interfaces réseau disponibles pour l'analyse, la seconde - les options d'ouverture des fichiers et la troisième - l'aide.
Analyse du trafic réseau
Pour démarrer l'analyse, sélectionnez une interface réseau, par exemple eth0, et cliquez sur le bouton Commencer.
Après cela, la fenêtre suivante s'ouvrira, avec déjà un flux de paquets qui transitent par l'interface. Cette fenêtre est également divisée en plusieurs parties :
- La partie supérieure- ce sont des menus et des panneaux avec divers boutons ;
- Liste des forfaits- puis le flux de paquets réseau que vous allez analyser s'affiche ;
- Contenu du colis- juste en dessous se trouve le contenu du colis sélectionné, il est réparti en catégories selon le niveau de transport ;
- De vraies performances- tout en bas, le contenu du colis est affiché sous forme réelle, ainsi que sous forme HEX.
Vous pouvez cliquer sur n’importe quel package pour analyser son contenu :
Ici, nous voyons un paquet de requête DNS pour obtenir l'adresse IP du site, dans la requête elle-même, le domaine est envoyé, et dans le paquet de réponse, nous recevons notre question ainsi que la réponse.
Pour une visualisation plus pratique, vous pouvez ouvrir le package dans une nouvelle fenêtre en double-cliquant sur l'entrée :
Filtres Wireshark
Parcourir manuellement les packages pour trouver ceux dont vous avez besoin est très gênant, surtout avec un thread actif. Par conséquent, pour cette tâche, il est préférable d’utiliser des filtres. Il y a une ligne spéciale sous le menu pour saisir les filtres. Vous pouvez cliquer Expression pour ouvrir le concepteur de filtres, mais il y en a beaucoup, nous allons donc examiner les plus basiques :
- ip.dst- adresse IP cible ;
- ip.src- l'adresse IP de l'expéditeur ;
- ip.addr- IP de l'expéditeur ou du destinataire ;
- ip.proto- protocole ;
- tcp.dstport- port de destination;
- tcp.srcport- port expéditeur ;
- ip.ttl- Filtre TTL, détermine la distance du réseau ;
- http.request_uri- l'adresse du site demandée.
Pour spécifier la relation entre un champ et une valeur dans un filtre, vous pouvez utiliser les opérateurs suivants :
- == - équivaut à;
- != - inégal;
- < - moins;
- > - plus;
- <= - inférieur ou égal ;
- >= - plus ou égal ;
- allumettes- expression régulière;
- contient- contient.
Pour combiner plusieurs expressions, vous pouvez utiliser :
- && - les deux expressions doivent être vraies pour le package ;
- || - une des expressions peut être vraie.
Examinons maintenant de plus près plusieurs filtres à l'aide d'exemples et essayons de comprendre tous les signes de relations.
Tout d'abord, filtrons tous les paquets envoyés au 194.67.215.. Tapez une chaîne dans le champ de filtre et cliquez sur Appliquer. Pour plus de commodité, les filtres Wireshark peuvent être enregistrés à l'aide du bouton Sauvegarder:
ip.dst == 194.67.215.125
Et afin de recevoir non seulement les paquets envoyés, mais aussi ceux reçus en réponse de ce nœud, vous pouvez combiner deux conditions :
ip.dst == 194.67.215.125 || ip.src == 194.67.215.125
Nous pouvons également sélectionner les fichiers volumineux transférés :
http.content_length > 5000
En filtrant le type de contenu, nous pouvons sélectionner toutes les images qui ont été téléchargées ; Analysons le trafic Wireshark, les paquets contenant le mot image :
http.content_type contient une image
Pour effacer le filtre, vous pouvez appuyer sur le bouton Clair. Il arrive que vous ne connaissiez pas toujours toutes les informations nécessaires au filtrage, mais que vous souhaitiez simplement explorer le réseau. Vous pouvez ajouter n'importe quel champ d'un package sous forme de colonne et afficher son contenu dans la fenêtre générale de chaque package.
Par exemple, je souhaite afficher le TTL (durée de vie) d'un paquet sous forme de colonne. Pour ce faire, ouvrez les informations du package, recherchez ce champ dans la section IP. Appelez ensuite le menu contextuel et sélectionnez l'option Appliquer comme colonne:
De la même manière, vous pouvez créer un filtre basé sur n'importe quel champ souhaité. Sélectionnez-le et affichez le menu contextuel, puis cliquez sur Appliquer comme filtre ou Préparer comme filtre, puis sélectionnez Choisi pour afficher uniquement les valeurs sélectionnées, ou Non séléctionné pour les supprimer :
Le champ spécifié et sa valeur seront appliqués ou, dans le second cas, insérés dans le champ filtre :
De cette façon, vous pouvez ajouter un champ de n'importe quel package ou colonne au filtre. Il y a aussi cette option dans le menu contextuel. Pour filtrer les protocoles, vous pouvez utiliser des conditions plus simples. Par exemple, analysons le trafic Wireshark pour les protocoles HTTP et DNS :
Une autre fonctionnalité intéressante du programme est l'utilisation de Wireshark pour suivre une session spécifique entre l'ordinateur de l'utilisateur et le serveur. Pour ce faire, ouvrez le menu contextuel du package et sélectionnez Suivre le flux TCP.
Une fenêtre s'ouvrira alors dans laquelle vous retrouverez toutes les données transférées entre le serveur et le client :
Diagnostiquer les problèmes de Wireshark
Vous vous demandez peut-être comment utiliser Wireshark 2.0 pour détecter les problèmes sur votre réseau. Pour ce faire, il y a un bouton rond dans le coin inférieur gauche de la fenêtre ; lorsque vous cliquez dessus, une fenêtre s'ouvre Outils Expet. Dans celui-ci, Wireshark collecte tous les messages d'erreur et problèmes de réseau :
La fenêtre est divisée en onglets tels que Erreurs, Avertissements, Avis, Chats. Le programme peut filtrer et trouver de nombreux problèmes de réseau, et ici vous pouvez les voir très rapidement. Les filtres Wireshark sont également pris en charge ici.
Analyse du trafic Wireshark
Vous pouvez très facilement comprendre ce que les utilisateurs ont téléchargé et quels fichiers ils ont consulté si la connexion n'était pas cryptée. Le programme fait un très bon travail d'extraction de contenu.
Pour ce faire, vous devez d'abord arrêter la capture de trafic à l'aide du carré rouge sur le panneau. Puis ouvrez le menu Déposer -> Exporter des objets -> HTTP:
