This page has been robot translated, sorry for typos if any. Original content here.

Attaques de réseau et autre chose

Introduction aux attaques réseau

Brève description des attaques de réseau

Fragmentation des données

Envoi de paquets IP fragmentés

Attaque d'inondation Ping

PingOfDeath ou SSPing

Bombe UDP

SYN inondation

Protocoles encapsulés IP non standard

Application du protocole TFTP

Attaque de Schtroumpf

Attaque terrestre

Déploiement d'un faux serveur sur Internet en créant une «tempête» directionnelle de fausses réponses DNS vers l'hôte attaqué

Déploiement d'un faux serveur sur Internet en interceptant une requête DNS ou en créant une «tempête» directionnelle de fausses réponses DNS sur le serveur DNS attaqué

Introduction d'un serveur DNS parasite sur Internet en interceptant une requête DNS

Inondation d'attaque DNS

Attaque d'usurpation DNS

Attaque d'usurpation d'adresse IP

Forfaits imposants

Sniffing - écoute du canal (possible uniquement dans le segment de réseau local)

Capture de paquets sur le routeur

Imposer une route parasite à un hôte en utilisant ICMP

Winnuke

Faux serveur ARP

Numéro de prédiction de séquence TCP (usurpation d'adresse IP)

Tempête locale

Détournement d'Ip

Détection d'attaque et protection

Méthodes d'analyse

Utiliser le protocole ARP

Numérisation réseau via DNS

Bombe UDP

Balayage de port TCP

Balayage de port UDP

Balayage furtif

Analyse passive

Le système d'invitation et le danger des informations qu'il contient

Quelques conseils pour la recherche en réseau

Quelques autres moyens d'obtenir des informations.

Trous et erreurs d'administration dans Windows NT

Spam

Comment protéger le système de messagerie contre les spammeurs

Comment fonctionnent les spammeurs

Trous IIS, WWW, FTP

Introduction aux attaques réseau

Intérêt accru pour les réseaux TCP / IP en raison de la croissance rapide d'Internet. Cependant, cela soulève des questions sur la manière de protéger vos ressources d'informations contre les attaques provenant d'un réseau externe. Si vous êtes connecté à Internet, votre système peut être attaqué. Les protocoles de la famille IP constituent la base de la construction d’intranets et de l’Internet mondial. Bien que le développement de TCP / IP ait été financé par le département américain de la Défense, TCP / IP n'est pas complètement sécurisé et permet divers types d'attaques décrits dans ce chapitre. Pour mener de telles attaques, un attaquant potentiel doit avoir le contrôle d'au moins un des systèmes connectés à Internet. L’une des méthodes d’analyse des menaces à la sécurité des systèmes informatiques consiste à attribuer à une classe distincte de menaces inhérentes uniquement aux réseaux informatiques. Cette classe de menaces s'appelle la classe des attaques à distance. Cette approche de la classification semble être valable en raison de la présence de caractéristiques fondamentales dans la construction de systèmes d'exploitation de réseau. La principale caractéristique de tout système d’exploitation réseau est que ses composants sont répartis dans l’espace et que la connexion entre eux est réalisée physiquement à l’aide de connexions réseau spéciales (câble coaxial, paire torsadée, fibre optique, etc.) et par programme utilisant le mécanisme de messagerie. Dans ce cas, tous les messages de contrôle et les données envoyés par un composant d'un système d'exploitation réseau à un autre composant sont transmis via des connexions réseau sous la forme de paquets d'échange. Cette fonctionnalité est la principale raison de l'émergence d'une nouvelle classe de menaces: les attaques à distance. Avec ce type d'attaque, l'attaquant interagit avec le destinataire des informations, l'expéditeur et / ou les systèmes intermédiaires, éventuellement en modifiant et / ou en filtrant le contenu des paquets TCP / IP. Ces types d'attaques semblent souvent techniquement difficiles à implémenter, mais pour un bon programmeur, il n'est pas difficile d'implémenter les outils appropriés. La possibilité de générer des paquets IP arbitraires est un élément clé des attaques actives. Les attaques à distance peuvent être classées par type d'impact: actif ou passif. Les attaques actives peuvent être divisées en deux parties. Dans le premier cas, l'attaquant prend certaines mesures pour intercepter et modifier le flux de réseau ou pour tenter de "prétendre" être un autre système. Dans le second cas, TCP / IP est utilisé pour rendre le système victime inopérant. Dans les attaques passives, les attaquants ne se révèlent en aucun cas et n'interagissent pas directement avec d'autres systèmes. En fait, tout se résume à surveiller les données disponibles ou les sessions de communication. Bien que les attaques passives puissent violer les politiques de sécurité du réseau. L'idée de détecter une attaque est simple: un certain trafic réseau correspond à toute attaque. Par conséquent, l'analyse du trafic vous permet d'identifier l'attaque et de détecter les «traces» de l'attaquant, c'est-à-dire. déterminer les adresses IP à partir desquelles l'impact de l'information a été effectué. Ainsi, la détection d'attaques est réalisée en contrôlant le flux d'informations, ce qui est réalisé en analysant le trafic réseau.

Brève description des attaques de réseau

Il convient de rappeler que des méthodes grossières telles que le ping dans les paquets volumineux ou l'inondation SYN peuvent inonder toute machine Internet ou sous-réseau, quelle que soit la configuration.

Fragmentation des données

Lorsqu'un paquet de données IP est transmis sur un réseau, ce paquet peut être divisé en plusieurs fragments. Plus tard, une fois parvenu au destinataire, le paquet est restauré à partir de ces fragments. Un attaquant peut provoquer l'envoi d'un grand nombre de fragments, ce qui provoque un débordement de la mémoire tampon logicielle côté réception et, dans certains cas, une panne du système.

Transmission de paquets IP fragmentés avec un volume total de plus de 64 Ko

Le nombre d'implémentations d'attaques utilisant la possibilité de fragmentation de paquets IP est assez important. Plusieurs paquets IP fragmentés sont transmis à l'ordinateur victime, qui, lorsqu'ils sont assemblés, forment un paquet supérieur à 64 Ko (la taille maximale du paquet IP est de 64 Ko moins la longueur de l'en-tête). Cette attaque était efficace contre les ordinateurs exécutant Windows. À la réception d'un tel package, Windows NT, qui ne possède pas de correctif icmp-fix spécial, se bloque ou se bloque. D'autres variantes de ces attaques utilisent des décalages incorrects dans les fragments IP, ce qui entraîne une allocation de mémoire incorrecte, un débordement de mémoire tampon et, finalement, des dysfonctionnements du système.

Contre-réaction: pour identifier de telles attaques, il est nécessaire de réaliser et d’analyser l’assemblage de paquets "à la volée", ce qui alourdira considérablement les besoins en matériel.

Attaque d'inondation Ping

Il est apparu parce que le programme "ping", conçu pour évaluer la qualité de la ligne, possède la clé des tests "agressifs". Dans ce mode, les demandes sont envoyées le plus rapidement possible et le programme vous permet d’évaluer le fonctionnement du réseau à la charge maximale. Cette attaque nécessite que l'attaquant accède à des canaux rapides sur Internet. Rappelez-vous comment fonctionne le ping. Le programme envoie un paquet ICMP de type ECHO REQUEST, en définissant l'heure et son identifiant. Le noyau de la machine réceptrice répond à une requête similaire avec le paquet ICMP ECHO REPLY. Après l'avoir reçu, ping donne la vitesse du paquet. En mode de fonctionnement standard, les paquets sont envoyés à certains intervalles, presque sans charger le réseau. Mais dans le mode «agressif», le flux ICMP d'écho de requête / réponse-paquet peut surcharger une petite ligne, la privant de sa capacité à transmettre des informations utiles. Naturellement, le cas du ping est un cas particulier d’une situation plus générale liée à la surcharge de canaux. Par exemple, un attaquant peut envoyer plusieurs paquets UDP sur le 19ème port de la machine victime et si, conformément aux règles généralement acceptées, il dispose d'un générateur de caractères sur le 19ème port UDP qui répond aux paquets avec des lignes de 80 octets. Notez qu'un attaquant peut également simuler l'adresse de retour de tels paquets, ce qui la rend plus difficile à détecter. Seul le travail coordonné de spécialistes sur les routeurs intermédiaires peut aider à le suivre, ce qui est pratiquement irréaliste. L'une des options d'attaque consiste à envoyer des paquets de requête d'écho ICMP avec l'adresse source pointant vers la victime vers les adresses de diffusion de grands réseaux. En conséquence, chacune des machines répondra à cette demande fictive et la machine émettrice recevra un plus grand nombre de réponses. L'envoi d'un grand nombre de demandes d'écho de diffusion de la part de la "victime" aux adresses de diffusion de grands réseaux peut être brusquement rempli avec le canal "victime". Signes d’inondation - augmentation de la charge sur le réseau (ou le canal) et augmentation du nombre de paquets spécifiques (tels que ICMP). À titre de protection, nous pouvons recommander la configuration de routeurs, dans lesquels ils filtreront le même trafic ICMP dépassant une valeur prédéterminée (paquets / unité de temps). Pour vous assurer que vos machines ne peuvent pas servir de source d’inondation de ping, limitez l’accès à ping.

PingOfDeath ou SSPing

Son essence est la suivante: un paquet ICMP très fragmenté de grande taille (64 Ko) est envoyé à la machine de la victime. La réponse des systèmes Windows à la réception d'un tel package est un blocage inconditionnel, y compris une souris et un clavier. Le programme d’attaque est largement disponible en ligne en tant que source C et en tant que fichier de lancement pour certaines versions d’Unix. Il est curieux de constater que, contrairement à WinNuke, non seulement les machines Windows peuvent être victimes d’une telle attaque, mais aussi MacOS et certaines versions de Unix. Les avantages de cette méthode d’attaque sont que le pare-feu ignore généralement les paquets ICMP. Si le pare-feu est configuré pour filtrer les adresses des expéditeurs, vous pouvez également tromper un tel pare-feu en utilisant de simples techniques d’espionnage. L'inconvénient de PingOfDeath est que pour une seule attaque, il est nécessaire d'envoyer plus de 64 Ko sur le réseau, ce qui le rend généralement peu utile pour les détournements à grande échelle.

Bombe UDP

Le paquet UDP transmis contient un format incorrect de champs de service. Certaines versions plus anciennes du logiciel réseau entraînent une panne du système lors de la réception d'un tel package.

SYN inondation

L'inondation de SYN-packs est le moyen le plus connu pour «boucher» le canal d'information. Rappelez le fonctionnement de TCP / IP pour les connexions entrantes. Le système répond au paquet C-SYN - S-SYN / C-ACK entrant par un paquet, transfère la session à l'état SYN_RECEIVED et la place dans une file d'attente. Si dans un délai spécifié du client ne vient pas S-ACK, la connexion est supprimée de la file d'attente, sinon la connexion est transférée à l'état ESTABLISHED. Prenons le cas où la file d'attente de connexion d'entrée est déjà pleine et que le système reçoit un paquet SYN qui vous invite à établir une connexion. Par RFC, il sera silencieusement ignoré. L'inondation des paquets SYN est basée sur le débordement de la file d'attente du serveur, après quoi le serveur cesse de répondre aux demandes des utilisateurs. L’attaque la plus célèbre de ce type est l’attaque de Panix, un fournisseur new-yorkais. Panix n'a pas fonctionné pendant 2 semaines. Dans divers systèmes, le travail avec la file d'attente est mis en œuvre de différentes manières. Ainsi, dans les systèmes BSD, chaque port a sa propre file d’attente de 16 éléments. Sur le système SunOS, au contraire, cette séparation n’existe pas et le système dispose simplement d’une file d’attente commune de grande taille. Par conséquent, pour bloquer, par exemple, le port WWW sur BSD, 16 paquets SYN suffisent et, pour Solaris 2.5, leur nombre sera beaucoup plus important. Après un certain temps (selon l'implémentation), le système supprime les demandes de la file d'attente. Cependant, rien n'empêche l'attaquant d'envoyer un nouveau lot de demandes. Ainsi, même avec une connexion à 2400 bps, un attaquant peut envoyer 20 à 30 paquets toutes les minutes et demie au serveur FreeBSD, en le maintenant inactif (bien sûr, cette erreur a été corrigée dans les versions récentes de FreeBSD). Comme d'habitude, un attaquant peut utiliser des adresses IP à retour aléatoire lors de la formation de paquets, ce qui rend difficile la détection et le filtrage de son trafic. La détection est facile - un grand nombre de connexions à l'état SYN_RECEIVED, ignorant les tentatives de connexion à ce port. À titre de protection, vous pouvez recommander des correctifs qui implémentent un «amincissement» automatique de la file d'attente, par exemple, basés sur l'algorithme Early Random Drop. Pour savoir si votre système est protégé contre le SYN-flooding, contactez le fournisseur de votre système. Une autre option de sécurité consiste à configurer le pare-feu de manière à ce que toutes les connexions TCP / IP entrantes soient définies par lui, et seulement après qu'il les transfère à l'intérieur du réseau vers la machine spécifiée. Cela vous permettra de limiter l’inondation de synchronisation et de ne pas la manquer à l’intérieur du réseau. Cette attaque est une attaque par déni de service qui empêche de fournir des services. L'attaque est généralement dirigée contre un service spécifique, tel que telnet ou ftp. Il consiste à transmettre des paquets pour établir une connexion au port correspondant au service attaqué. Lorsqu'une demande est reçue, le système alloue des ressources pour une nouvelle connexion, après quoi il essaie de répondre à la demande (envoyer un "SYN-ACK") à une adresse indisponible. Par défaut, les versions 3.5 à 4.0 de NT essaieront de répéter la confirmation 5 fois - après 3, 6, 12, 24 et 48 secondes. Après cela, le système peut attendre 96 secondes supplémentaires avant d’attendre une réponse. Il libère ensuite les ressources allouées pour la future connexion. Le temps total d'utilisation de la ressource est de 189 secondes.

Protocoles encapsulés IP non standard

Le paquet IP contient un champ qui définit le protocole du paquet encapsulé (TCP, UDP, ICMP). Les attaquants peuvent utiliser une valeur non standard de ce champ pour transmettre des données qui ne seront pas enregistrées par des moyens standard de contrôle des flux d'informations.

Application du protocole TFTP

Ce protocole ne contient pas de mécanismes d'authentification, il est donc attrayant pour les intrus.

Attaque de Schtroumpf

L'attaque de smurf consiste à envoyer des demandes au réseau de diffusion ICMP pour le compte de l'ordinateur victime. En conséquence, les ordinateurs ayant reçu de tels paquets de diffusion répondent à l'ordinateur victime, ce qui entraîne une réduction importante de la bande passante du canal de communication et, dans certains cas, une isolation complète du réseau attaqué. L’attaque du smurf est extrêmement efficace et généralisée. Contre-réaction: pour reconnaître cette attaque, il est nécessaire d'analyser la charge du canal et de déterminer les raisons de la diminution du débit.

Attaque terrestre

Land Attack exploite les vulnérabilités d'implémentation de pile TCP / IP dans certains systèmes d'exploitation. Il consiste à transmettre un paquet TCP au port ouvert de l'ordinateur victime avec l'indicateur SYN défini, et l'adresse source et le port du paquet sont respectivement égaux à l'adresse et au port de l'ordinateur attaqué. Cela entraîne le fait que l'ordinateur victime tente d'établir une connexion avec lui-même, ce qui augmente considérablement la charge du processeur et peut provoquer un «blocage» ou un redémarrage. Cette attaque est très efficace sur certains modèles de routeurs Cisco Systems. L'application réussie de l'attaque au routeur peut désactiver l'ensemble du réseau de l'organisation. Counteraction: vous pouvez vous protéger de cette attaque, par exemple, en installant un filtre de paquets entre le réseau interne et Internet, en définissant une règle de filtrage qui indique de supprimer les paquets provenant d'Internet, mais avec les adresses IP d'origine des ordinateurs du réseau interne.

Déploiement d'un faux serveur sur Internet en créant une «tempête» directionnelle de fausses réponses DNS vers l'hôte attaqué

Une autre variante de la mise en œuvre d'une attaque à distance visant le service DNS est basée sur le deuxième type d'attaque à distance «faux objet du soleil». Dans ce cas, l'attaquant envoie en permanence à l'hôte attaqué une réponse DNS fausse préalablement préparée pour le compte du serveur DNS réel sans recevoir de requête DNS. En d'autres termes, un attaquant crée une «tempête» dirigée de fausses réponses DNS sur Internet. Cela est possible car le protocole UDP est généralement utilisé pour transmettre une requête DNS dans laquelle il n’existe aucun moyen d’identifier les paquets. Les seuls critères indiqués par le système d'exploitation de l'hôte pour la réponse reçue du serveur DNS sont, d'une part, la correspondance de l'adresse IP de l'expéditeur avec l'adresse IP du serveur DNS, et d'autre part, que le même nom est spécifié dans la réponse DNS, comme dans la requête DNS, troisièmement, la réponse DNS doit être dirigée vers le même port UDP à partir duquel la requête DNS a été envoyée (dans ce cas, il s'agit du premier problème pour l'attaquant) et, quatrièmement, dans le serveur DNS. - l'identifiant de champ de réponse de la demande dans l'en-tête DNS (ID) doit contenir la même valeur que dans la requête DNS transmise (c'est le deuxième problème). Dans ce cas, l'attaquant ne pouvant pas intercepter la requête DNS, le principal problème pour lui est le numéro de port UDP à partir duquel la requête a été envoyée. Mais le numéro de port de l'expéditeur accepte un ensemble limité de valeurs (1023?). Par conséquent, il suffit qu'un attaquant agisse par une simple recherche en envoyant de fausses réponses à la liste de ports correspondante. À première vue, le deuxième problème peut être un identifiant de deux octets de la requête DNS, mais dans ce cas, il est égal à un ou sa valeur est proche de zéro (une requête - l'ID est incrémenté de 1). Par conséquent, pour mener à bien cette attaque à distance, un attaquant doit sélectionner l'hôte d'intérêt (A), la route sur laquelle vous souhaitez changer, afin qu'il passe par un faux serveur, l'hôte de l'attaquant. Ceci est réalisé par une transmission constante (dirigée par «l'orage») à l'attaquant de fausses réponses DNS à l'hôte attaqué pour le compte du serveur DNS réel aux ports UDP correspondants. Ces fausses réponses DNS indiquent l'adresse IP de l'hôte A en tant qu'adresse IP de l'attaquant. Ensuite, l'attaque est développée comme suit. Dès que la cible de l'attaque (hôte attaqué) adresse l'hôte A par son nom , une requête DNS est envoyée au réseau à partir de cet hôte, ce que l'attaquant ne recevra jamais, mais cela n'est pas obligatoire car l'hôte recevra immédiatement un message faux constamment transmis. La réponse DNS, qui sera perçue par le système d'exploitation de l'hôte attaqué comme la réponse réelle du serveur DNS. L’attaque a eu lieu et l’hôte attaqué transférera tous les paquets destinés à A à l’adresse IP de l’hôte de l’attaquant, qui les transmettra à A , affectant ainsi les informations interceptées selon le schéma du "faux objet du VS distribué". Considérez le schéma fonctionnel de l'attaque à distance proposée sur le service DNS: • transmission continue de fausses réponses DNS à l'hôte attaqué vers différents ports UDP et, éventuellement, avec différents identifiants, à partir du nom (de l'adresse IP) de ce serveur DNS, indiquant le nom de l'hôte d'intérêt et sa fausse adresse IP, qui seront être l'adresse IP du faux serveur - l'hôte de l'attaquant; • dans le cas de réception d'un paquet d'un hôte, changer l'en-tête IP du paquet avec son adresse IP en adresse IP de l'attaquant et envoyer le paquet au serveur (en d'autres termes, le faux serveur travaille avec le serveur pour son propre compte à partir de son adresse IP); • dans le cas de la réception d'un paquet du serveur, changer l'en-tête IP du paquet avec son adresse IP en l'adresse IP du serveur parasite et envoyer le paquet à l'hôte (pour l'hôte, le serveur parasite est le serveur réel). Ainsi, la mise en œuvre de cette attaque à distance, qui utilise des failles de sécurité dans le service DNS, permet de perturber le routage entre deux objets spécifiés à partir de n’importe où sur Internet. C'est-à-dire que cette attaque à distance est intersegmentale pour la cible de l'attaque et menace la sécurité de tout hôte Internet utilisant un DNS normal.

Déploiement d'un faux serveur sur Internet en interceptant une requête DNS ou en créant une «tempête» directionnelle de fausses réponses DNS sur le serveur DNS attaqué

Dans le schéma de recherche DNS distant, il s'ensuit que si le nom du serveur DNS spécifié dans la demande ne trouve pas de noms dans sa base de données, la demande est envoyée par le serveur à l'un des serveurs DNS racine dont les adresses figurent dans le fichier de paramètres du serveur root.cache. . Autrement dit, si le serveur DNS ne dispose pas d'informations sur l'hôte demandé, il transmet ensuite la demande, ce qui signifie que le serveur DNS lui-même est l'initiateur de la recherche DNS à distance. Par conséquent, rien n'empêche l'attaquant, en utilisant les méthodes décrites dans le paragraphe précédent, de diriger son attaque sur le serveur DNS. En d'autres termes, la cible de l'attaque ne sera plus l'hôte, mais le serveur DNS et les réponses DNS fausses seront envoyées par l'attaquant pour le compte du serveur DNS racine au serveur DNS attaqué. Il est important de prendre en compte les fonctionnalités suivantes du serveur DNS. Pour accélérer le travail, chaque serveur DNS met en cache ses propres noms d'hôte et adresses IP dans la zone de mémoire. Le cache contient des informations modifiables de manière dynamique sur les noms et adresses IP des hôtes trouvés lors du fonctionnement du serveur DNS. En d’autres termes, si un serveur DNS, lorsqu’il reçoit une demande, ne trouve pas l’enregistrement correspondant dans sa table de cache, il transmet la réponse au serveur suivant et, à la réception de cette réponse, stocke en mémoire les informations trouvées dans la table de cache. Ainsi, lors de la réception de la demande suivante, le serveur DNS n’est plus obligé d’effectuer une recherche à distance, car les informations nécessaires se trouvent déjà dans sa table de mémoire cache. À partir de l'analyse du schéma de recherche DNS distant décrit ci-dessus, il devient évident que si un attaquant envoie une fausse réponse DNS en réponse à une requête du serveur DNS (ou dans le cas d'un «orage», des réponses fausses les enverront de manière permanente), puis une entrée correspondante contenant de fausses informations apparaîtra dans la table de cache du serveur, puis tous les hôtes accédant à ce serveur DNS seront mal informés. Lors de l'accès à l'hôte, la route sur laquelle l'attaquant a décidé de changer, la connexion avec ce dernier est établie via l'hôte de l'attaquant. selon les régimes e "faux objet d'avion". Et au fil du temps, ces fausses informations entrées dans la mémoire cache du serveur DNS seront distribuées aux serveurs DNS voisins des niveaux supérieurs et, par conséquent, de plus en plus d'hôtes sur Internet seront mal informés et attaqués. Évidemment, dans l'éventualité où un attaquant ne pourrait pas intercepter une requête DNS d'un serveur DNS, il lui fallait un «assaut» de fausses réponses DNS envoyées au serveur DNS pour pouvoir lancer une attaque. Dans ce cas, le problème principal suivant se pose, différent du problème de sélection de port en cas d'attaque dirigée contre l'hôte. Comme indiqué précédemment, le serveur DNS, en envoyant une demande à un autre serveur DNS, identifie la demande avec une valeur à deux octets (ID). Cette valeur est incrémentée de un à chaque demande envoyée. Pour connaître l'attaquant est la valeur actuelle de l'identificateur de la requête DNS n'est pas possible. Par conséquent, il est assez difficile de proposer autre chose que l'énumération de 2 16 valeurs ID possibles. Mais le problème de contournement de port disparaît, car toutes les requêtes DNS sont transmises par le serveur DNS au port 53. Le problème suivant, qui est une condition préalable à la mise en œuvre de cette attaque à distance sur le serveur DNS en cas de «tempête» de fausses réponses DNS, est que l'attaque ne réussira que si le serveur DNS envoie une requête pour rechercher un nom spécifique (qui contient dans une fausse réponse DNS). Le serveur DNS envoie cette requête, qui est si nécessaire et souhaitable pour un attaquant, si une requête DNS provient d’un hôte pour rechercher un nom donné et ce nom dans la table de cache du serveur DNS. En principe, cette demande peut arriver à tout moment et l'attaquant peut être obligé d'attendre les résultats de l'attaque pendant un temps arbitrairement long. Cependant, rien n'empêche l'attaquant, sans attendre personne, d'envoyer une requête DNS similaire au serveur DNS attaqué et de provoquer le serveur DNS à rechercher le nom spécifié dans la requête. Ensuite, cette attaque est susceptible de réussir presque immédiatement après le début de sa mise en œuvre.

Introduction d'un serveur DNS parasite sur Internet en interceptant une requête DNS

Dans ce cas, il s'agit d'une attaque à distance basée sur une attaque à distance standard standard, associée à l'attente d'une requête de recherche DNS. Avant de considérer l'algorithme d'attaque sur le service DNS, vous devez faire attention aux subtilités suivantes dans le travail de ce service. Premièrement, par défaut, le service DNS fonctionne sur la base du protocole UDP (bien qu'il soit possible d'utiliser le protocole TCP), ce qui le rend naturellement moins sécurisé, car le protocole UDP, contrairement à TCP, ne fournit pas de moyen d'identifier les messages. Afin de passer d'UDP à TCP, l'administrateur du serveur DNS devra étudier la documentation très sérieusement. De plus, cette transition ralentira quelque peu le système car, d’une part, lorsqu’on utilise TCP, une connexion virtuelle est requise et, d’autre part, les systèmes d’exploitation réseau finals envoient d’abord une requête DNS à l’aide du protocole UDP et s’ils parviennent à leur destination finale. une réponse spéciale du serveur DNS, le système d’exploitation du réseau enverra une requête DNS en utilisant TCP. Deuxièmement, la subtilité suivante à prendre en considération est que la valeur du champ "port de l'expéditeur" dans le paquet UDP prend d'abord la valeur 1023 (?) Et augmente ensuite à chaque demande DNS transmise. Troisièmement, la valeur de l'identifiant (ID) de la requête DNS se comporte comme suit. Dans le cas d'un transfert de requête DNS à partir d'un hôte, sa valeur dépend de l'application réseau spécifique qui génère la requête DNS. Les expériences de l'auteur ont montré qu'en cas de transfert d'une requête depuis le shell de l'interpréteur de commandes des systèmes d'exploitation Linux et Windows '95 (par exemple, ftp nic.funet.fi), cette valeur est toujours égale à un. Si une requête DNS est transmise à partir de Netscape Navigator, à chaque nouvelle requête, le navigateur lui-même augmente cette valeur de un. Dans ce cas, si la requête est transmise directement par le serveur DNS, le serveur augmente la valeur de l'identifiant de un à chaque nouvelle requête transmise. Toutes ces subtilités importent en cas d’attaque sans intercepter une requête DNS. Pour mettre en œuvre une attaque en interceptant une requête DNS, un attaquant doit intercepter la requête DNS, extraire le numéro de port UDP de l'expéditeur de la requête, la valeur à deux octets de l'ID de la requête DNS et le nom que vous recherchiez, puis envoyer une fausse réponse DNS à la requête DNS. Un port UDP dans lequel spécifier comme adresse IP souhaitée la véritable adresse IP du faux serveur DNS. Cela permettra à l'avenir d'intercepter complètement et d'influencer activement le schéma "Faux objet RVS" sur le trafic entre l'hôte "trompé" et le serveur. Considérons un schéma généralisé d'un faux serveur DNS: • en attente d'une requête DNS; • après avoir reçu une demande DNS, en extraire les informations nécessaires et envoyer une fausse réponse DNS sur le réseau à l'hôte demandeur, pour le compte (de l'adresse IP) du serveur DNS réel, qui indique l'adresse IP du faux serveur DNS; • dans le cas de la réception d'un paquet provenant d'un hôte, changer l'en-tête IP du paquet avec son adresse IP en adresse IP du serveur DNS parasite et transférer le paquet sur le serveur (en d'autres termes, le serveur DNS parasite travaille avec le serveur en son propre nom); • dans le cas de la réception d'un paquet du serveur, changer son adresse IP dans l'en-tête du paquet en l'adresse IP du faux serveur DNS et transférer le paquet à l'hôte (pour l'hôte, le faux serveur DNS est le vrai serveur). Une condition nécessaire pour la mise en oeuvre de cette variante de l'attaque est l'interception de la requête DNS. Cela n'est possible que si l'attaquant se trouve sur le chemin de trafic principal ou dans un segment d'un serveur DNS réel. La réalisation d'une de ces conditions pour la localisation d'un attaquant sur le réseau rend une telle attaque distante difficile à mettre en œuvre dans la pratique (il est probable que l'attaquant ne pourra pas accéder au segment de serveur DNS ni, en outre, au canal de communication inter-segment). Toutefois, si ces conditions sont remplies, il est possible d'effectuer une attaque à distance entre segments sur Internet . Notez que la mise en œuvre pratique de cette attaque à distance a révélé un certain nombre de fonctionnalités intéressantes dans le fonctionnement du protocole FTP et dans le mécanisme d'identification des paquets TCP. Si le client FTP de l'hôte se connecte au serveur FTP distant via un faux serveur DNS, il s'avère que chaque fois que l'utilisateur émet une commande d'application FTP (par exemple, ls, get, put, etc.), le client FTP J’ai travaillé sur la commande PORT, qui consistait à envoyer le numéro de port et l’ adresse IP de l’hôte client au serveur FTP dans le champ de données du paquet TCP (il est difficile de trouver une signification spéciale à ces actions - pourquoi envoyer chaque fois l’adresse IP du client au serveur FTP)! Cela a conduit au fait que si un faux serveur DNS ne modifie pas l'adresse IP transmise dans le champ de données d'un paquet TCP et ne transfère ce paquet à un serveur FTP de la manière habituelle, le paquet suivant sera alors transmis par un serveur FTP à un hôte client FTP, en contournant un faux serveur DNS et, ce qui est très intéressant, ce paquet sera perçu comme un paquet normal et, de plus, un faux serveur DNS perdra le contrôle du trafic entre le serveur FTP et le client FTP! Cela est dû au fait qu'un serveur FTP standard ne fournit aucune identification supplémentaire du client FTP, mais il déplace tous les problèmes d'identification de paquet et de connexion vers un niveau inférieur - le niveau TCP.

Inondation d'attaque DNS

L'inondation DNS est une attaque dirigée contre les serveurs de noms Internet. Elle consiste à transmettre un grand nombre de requêtes DNS et conduit au fait que les utilisateurs ne peuvent pas accéder au service de noms. Il est donc impossible aux utilisateurs ordinaires de travailler. Counteraction: pour détecter cette attaque, il est nécessaire d'analyser la charge du serveur DNS et d'identifier les sources des requêtes.

Attaque d'usurpation DNS

Le résultat de cette attaque est l’introduction d’une correspondance imposée entre l’adresse IP et le nom de domaine dans le cache du serveur DNS. Suite au succès d’une telle attaque, tous les utilisateurs du DNS du nord recevront des informations incorrectes sur les noms de domaine et les adresses IP. Cette attaque est caractérisée par un grand nombre de paquets DNS portant le même nom de domaine. Cela est dû à la nécessité de sélectionner certains paramètres de l'échange DNS. Counteraction: pour détecter une telle attaque, il est nécessaire d'analyser le contenu du trafic DNS.

Attaque d'usurpation d'adresse IP (syslog)

Un grand nombre d'attaques sur Internet est associé à la substitution de l'adresse IP source. Parmi ces attaques, citons spoofing syslog, qui consiste à envoyer un message à l’ordinateur de la victime pour le compte d’un autre ordinateur du réseau interne. Le protocole syslog étant utilisé pour conserver les journaux système, il est possible d'imposer des informations ou de supprimer les traces d'accès non autorisés en envoyant de faux messages à l'ordinateur victime. Contre-action: la détection d’attaques liées à la substitution d’adresses IP est possible lors du contrôle de la réception d’un paquet avec l’adresse source de la même interface sur l’une des interfaces ou lors du contrôle de la réception des paquets avec les adresses IP du réseau interne de l’interface externe.

Forfaits imposants

Un attaquant envoie des paquets avec une fausse adresse de retour sur le réseau. Avec cette attaque, un attaquant peut commuter les connexions entre d’autres ordinateurs sur son ordinateur. Dans ce cas, les droits d'accès de l'attaquant deviennent égaux à ceux de l'utilisateur dont la connexion au serveur a été commutée sur l'ordinateur de l'attaquant.

Sniffing - écoute du canal (possible uniquement dans le segment de réseau local)

Pratiquement toutes les cartes réseau prennent en charge la capacité d'intercepter les paquets transmis sur un canal commun du réseau local. Dans ce cas, le poste de travail peut recevoir des paquets adressés à d'autres ordinateurs du même segment de réseau. Ainsi, l'intégralité de l'échange d'informations dans le segment de réseau devient disponible pour l'attaquant. Pour implémenter cette attaque avec succès, l'ordinateur de l'attaquant doit se trouver sur le même segment de réseau local que l'ordinateur attaqué.

Détournement de paquets sur le routeur

Le logiciel réseau du routeur a accès à tous les paquets réseau transmis par ce routeur, ce qui permet l'interception des paquets. Pour mettre en œuvre cette attaque, l'attaquant doit disposer d'un accès privilégié à au moins un routeur de réseau. Étant donné qu'un grand nombre de paquets sont généralement transmis via un routeur, leur interception totale est presque impossible. Cependant, des paquets individuels peuvent très bien être interceptés et enregistrés pour une analyse ultérieure par un attaquant. L'interception la plus efficace des paquets FTP contenant des mots de passe utilisateur, ainsi que du courrier électronique.

Imposer une route parasite à un hôte en utilisant ICMP

Sur Internet, il existe le protocole ICMP (Internet Control Message Protocol), dont l’une des fonctions est d’informer les hôtes du changement de routeur actuel. Ce message de contrôle s'appelle redirection. Il est possible d'envoyer un faux message de redirection de n'importe quel hôte du segment de réseau au nom du routeur à l'hôte attaqué. En conséquence, l'hôte modifie la table de routage actuelle et, à l'avenir, tout le trafic réseau de cet hôte passera, par exemple, par l'hôte qui a envoyé un faux message de redirection. Ainsi, il est possible d'imposer activement une fausse route dans un segment d'Internet.

Winnuke

Outre les données habituelles envoyées via une connexion TCP, le standard envoie également des données (hors bande). Au niveau des formats de paquets TCP, cela est exprimé dans un pointeur urgent différent de zéro. La plupart des PC sur lesquels Windows est installé ont un protocole réseau NetBIOS qui utilise 3 ports IP: 137, 138, 139. Il s’est avéré que si vous vous connectez à une machine Windows à 139 ports et envoyez plusieurs octets de données OutOfBand, la mise en oeuvre de NetBIOS sans savoir quoi faire avec ces données, il se bloque ou redémarre simplement. Pour Windows 95, cela ressemble généralement à un écran de texte bleu, signalant une erreur dans le pilote TCP / IP et l'impossibilité de travailler avec le réseau avant le redémarrage du système d'exploitation. NT 4.0 sans service pack est redémarré, NT 4.0 avec un deuxième service pack s'affiche dans un écran bleu. Un envoi similaire de données à 135 et à certains autres ports entraîne une charge importante sur le processeur RPCSS.EXE. Sur NTWS, cela entraîne un ralentissement important, le SNRC est presque gelé.

Faux serveur ARP

Sur Internet, chaque hôte a une adresse IP unique, qui reçoit tous les messages du réseau mondial. Cependant, le protocole IP n'est pas tant un réseau qu'un protocole d'échange Internet conçu pour la communication entre des objets d'un réseau mondial. Au niveau de la liaison, les paquets sont adressés aux adresses matérielles des cartes réseau. Internet utilise le protocole ARP (Address Resolution Protocol) pour la correspondance un à un entre adresses IP et Ethernet. Initialement, un hôte peut ne pas avoir d'informations sur les adresses Ethernet des autres hôtes qui le composent dans le même segment, y compris l'adresse Ethernet du routeur. En conséquence, lors du premier accès aux ressources du réseau, l'hôte envoie une demande ARP de diffusion que toutes les stations du segment de réseau recevront. À la réception de cette demande, le routeur envoie une réponse ARP à l'hôte demandeur, dans laquelle il indique son adresse Ethernet. Ce schéma d'opération permet à un attaquant d'envoyer une fausse réponse ARP, dans laquelle il se déclare l'hôte souhaité (par exemple, un routeur) et, par la suite, surveille activement tout le trafic réseau de l'hôte "trompé".

Numéro de prédiction de séquence TCP (usurpation d'adresse IP)

Dans ce cas, l'objectif de l'attaquant est de prétendre être un autre système, qui, par exemple, est «approuvé» par le système victime. La méthode est également utilisée à d'autres fins - par exemple, utiliser le SMTP de la victime pour envoyer de faux courriels. La connexion TCP est établie en trois étapes: le client sélectionne et envoie le numéro de séquence au serveur (appelons-le C-SYN). En réponse, le serveur envoie au client un paquet de données contenant une confirmation (C-ACK) et son propre numéro de séquence (S-SYN). ). Maintenant, le client doit envoyer une confirmation (S-ACK). Après cela, la connexion est considérée comme établie et l'échange de données commence. De plus, chaque paquet a un en-tête dans l'en-tête pour le numéro de séquence et le numéro d'accusé de réception. Ces chiffres augmentent avec l’échange de données et vous permettent de contrôler l’exactitude du transfert. Supposons qu'un attaquant puisse prédire quel numéro de séquence (S-SYN selon le schéma) sera envoyé par le serveur. Cela peut être fait en fonction de la connaissance d'une implémentation TCP / IP spécifique. Par exemple, dans 4.3BSD, la valeur du numéro de séquence, qui sera utilisée lors de la définition de la valeur suivante, augmente de 125 000 toutes les secondes. Ainsi, en envoyant un paquet au serveur, l'attaquant recevra une réponse et pourra (éventuellement, plusieurs fois et corrigé pour la vitesse de connexion) Le numéro de séquence pour la prochaine connexion. Si la mise en œuvre TCP / IP utilise un algorithme spécial pour déterminer le numéro de séquence, vous pouvez le clarifier en envoyant plusieurs dizaines de paquets au serveur et en analysant ses réponses. Supposons donc que le système A approuve le système B, de sorte que l'utilisateur du système B puisse effectuer "rlogin A" et se retrouver sur A sans entrer de mot de passe. Supposons que l'attaquant se trouve sur le système C. Le système A agit en tant que serveur, les systèmes B et C en tant que clients. La première tâche de l'attaquant consiste à placer le système B dans un état dans lequel il ne peut pas répondre aux requêtes du réseau. Cela peut être fait de plusieurs façons: dans le cas le plus simple, il vous suffit d’attendre le redémarrage du système B. Quelques minutes, pendant lesquelles il sera inopérant, devraient suffire. Après cela, l’attaquant peut essayer de se faire passer pour le système B afin d’avoir accès au système A (au moins à court terme). L'attaquant envoie plusieurs paquets IP qui initient la connexion, au système A, pour connaître l'état actuel du numéro de séquence du serveur. L'attaquant envoie un paquet IP dans lequel l'adresse du système B est déjà spécifiée comme adresse de retour. Le système A répond avec un paquet avec un numéro de séquence envoyé au système B. Cependant, le système B ne le recevra jamais (il est désactivé), comme l'attaquant. Mais sur la base de l'analyse précédente, il devine quel numéro de séquence a été envoyé au système B. L'attaquant confirme que le paquet a été reçu de A, envoyant un paquet avec un S-ACK estimé pour le compte de B (notez que si les systèmes sont situés dans le même segment, l'attaquant déterminera la séquence nombre suffit pour intercepter un paquet envoyé par le système A). Par la suite, si l’attaquant a de la chance et que le numéro de séquence du serveur a été correctement deviné, la connexion est considérée comme établie. Un attaquant peut maintenant envoyer un autre faux paquet IP, qui contiendra déjà des données. Par exemple, si l’attaque visait rsh, elle pourrait contenir des commandes permettant de créer un fichier .rhosts ou d’envoyer / etc / passwd à un attaquant par courrier électronique. Contre-réaction: le signal le plus simple de l'usurpation d'adresse IP sera constitué de paquets d'adresses externes provenant du monde extérieur. Le logiciel du routeur peut alerter l'administrateur. Cependant, ne vous flattez pas, l'attaque peut provenir de votre réseau. Dans le cas d'outils de surveillance réseau plus intelligents, l'administrateur peut surveiller (en mode automatique) les paquets provenant de systèmes dont l'état n'est pas disponible. Cependant, qu'est-ce qui empêche un attaquant d'imiter le fonctionnement du système B en répondant aux paquets ICMP? Quels sont les moyens de se protéger contre l'usurpation d'adresse IP? Tout d'abord, il est possible de rendre difficile ou impossible de deviner le numéro de séquence (l'élément clé de l'attaque). Par exemple, vous pouvez augmenter le taux de changement du numéro de séquence sur le serveur ou sélectionner le nombre d'augmentation du numéro de séquence de manière aléatoire (en utilisant de préférence un algorithme cryptographiquement robuste pour générer des nombres aléatoires). Si le réseau utilise un pare-feu (ou un autre filtre de paquets IP), vous devez y ajouter des règles selon lesquelles tous les paquets provenant de l'extérieur et ayant des adresses de retour de notre espace d'adressage ne doivent pas être autorisés à l'intérieur du réseau. En outre, vous devez minimiser la confiance des machines les unes envers les autres. Dans l’idéal, il ne devrait y avoir aucun moyen d’accéder directement à la machine du réseau suivant, après avoir obtenu les droits de superutilisateur sur l’une d’elles. Bien entendu, cela ne vous évitera pas l'utilisation de services ne nécessitant pas d'autorisation, par exemple, IRC (un attaquant peut prétendre être une machine Internet arbitraire et envoyer un ensemble de commandes pour entrer dans le canal IRC, émettre des messages arbitraires, etc.). Le cryptage d'un flux TCP / IP résout le problème d'usurpation d'adresse IP en général (à condition que des algorithmes cryptographiquement puissants soient utilisés). Afin de réduire le nombre de telles attaques, il est également recommandé de configurer le pare-feu pour filtrer les paquets envoyés vers l'extérieur par notre réseau, mais dont les adresses n'appartiennent pas à notre espace adresse.

Tempête locale

Faisons une petite digression vers la mise en œuvre de TCP / IP et considérons les "tempêtes locales" comme un exemple de tempête UDP. En règle générale, les systèmes prennent en charge le travail de ports UDP tels que 7 ("echo", le paquet reçu est renvoyé), 19 ("générateur de caractères", le caractère du générateur de chaîne est envoyé à l'expéditeur en réponse au paquet reçu) et autres (date, etc.). Dans ce cas, un attaquant peut envoyer un seul paquet UDP, où 7 sera spécifié comme port source, le 19ème comme destinataire et, par exemple, deux machines de votre réseau (ou même 127.0) seront indiquées comme adresses du destinataire et de l'expéditeur. 0,1). Ayant reçu le paquet, le 19ème port répond avec une chaîne qui va au port 7. Le septième port le duplique et le renvoie à 19. Et ainsi de suite à l'infini. Le cycle sans fin consomme les ressources des machines et ajoute une charge insignifiante au canal. Bien sûr, avec le premier paquet UDP perdu, la tempête va s'arrêter. Противодействие: в качестве защиты стоит еще раз порекомендовать не пропускать в сети пакеты с внутренними адресами, но пришедшие извне. Также рекомендуется закрыть на firewall использование большинства сервисов.

IP Hijacking

Метод является комбинацией 'подслушивания' и IP-spoofing'а. Необходимые условия - злоумышленник должен иметь доступ к машине, находящейся на пути сетевого потока и обладать достаточными правами на ней для генерации и перехвата IP-пакетов. Напомним, что при передаче данных постоянно используются sequence number и acknowledge number (оба поля находятся в IP-заголовке). Исходя из их значения, сервер и клиент проверяют корректность передачи пакетов. Существует возможность ввести соединение в "десинхронизированное состояние", когда присылаемые сервером sequence number и acknowledge number не будут совпадать с ожидаемым значениеми клиента, и наоборот. В данном случае злоумышленник, "прослушивая" линию, может взять на себя функции посредника, генерируя корректные пакеты для клиента и сервера и перехватывая их ответы. Метод позволяет полностью обойти такие системы защиты, как, например, одноразовые пароли, поскольку злоумышленник начинает работу уже после того, как произойдет авторизация пользователя. Есть два способа рассинхронизировать соединение. • Ранняя десинхронизация. Соединение десинхронизируется на стадии его установки. Злоумышленник прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии. Дождавшись пакета S-SYN от сервера, злоумышленник высылает серверу пакет типа RST (сброс), конечно, с корректным sequence number, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым sequence number, после чего посылает клиенту новый S-SYN-пакет. Клиент игнорирует S-SYN-пакет, однако злоумышленник, прослушивающий линию, высылает серверу S-ACK-пакет от имени клиента. Итак, клиент и сервер находятся в состоянии ESTABLISHED, однако сессия десинхронизирована. Естественно, 100% срабатывания у этой схемы нет, например, она не застрахована от того, что по дороге не потеряются какие-то пакеты, посланные злоумышленником. Для корректной обработки этих ситуаций программа должна быть усложнена. • Десинхронизация нулевыми данными. В данном случае злоумышленник прослушивает сессию и в какой-то момент посылает серверу пакет с "нулевыми" данными, т.е. такими, которые фактически будут проигнорированы на уровне прикладной программы и не видны клиенту (например, для telnet это может быть данные типа IAC NOP IAC NOP IAC NOP...). Аналогичный пакет посылается клиенту. Очевидно, что после этого сессия переходит в десинхронизированное состояние. ACK-буря Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии вызывает так называемый ACK-бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на этот неприемлимый уже для сервера пакет клиент вновь получает ответ. И так до бесконечности. К счастью современные сети строятся по технологиям, когда допускается потеря отдельных пакетов. Поскольку ACK-пакеты не несут данных, повторных передачи не происходит и "буря стихает". Как показали опыты, чем сильнее ACK-буря, тем быстрее она "утихомиривает" себя - на 10MB ethernet это происходит за доли секунды. На ненадежных соединениях типа SLIP - ненамного больше. Детектирование и защита Есть несколько путей. Например, можно реализовать TCP/IP-стек, который будут контролировать переход в десинхронизированное состояние, обмениваясь информацией о sequence number/acknowledge number. Однако в данном случае мы не застрахованы от злоумышленника, меняющего и эти значения. Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающих ACK-бурь. Это можно реализовать при помощи конкретных средств контроля за сетью. Если злоумышленник не потрудиться поддерживать десинхронизированное соединение до его закрытия или не станет фильтровать вывод своих команд, это также будет сразу замечено пользователем. К сожалению, подавляющее большинство просто откруют новую сессию, не обращаясь к администратору. Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP-трафика (на уровне приложений - secure shell) или на уровн протокола - IPsec). Это исключает возможность модификации сетевого потока. Для защиты почтовых сообщений может применяться PGP. Следует заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP/IP. Так, несмотря на [rfc...], который требует молчаливого закрытия сесии в ответ на RST-пакет, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию.

Обнаружение атак и защита от них

• Для обнаружения атак можно анализировать широковещательную активность - это пакеты UDP, NBF, SAP. • Для защиты внутренней сети, подключенной к Internet'у, не стоит пропускать из внешней сети входящие пакеты, источником в которых стоит внутренний сетевой адрес. Можно разрешить проходить пакетам только на порт 80. • Ставьте фильтрацию пакетов, если необходимо (не стоит пренебрегать даже
Control Panel\Network\Protocols\Properties\Advanced в Windows NT).

Методы сканирования

Использование протокола ARP

Данный тип запросов может быть использован злоумышленниками для определения функционирующих систем в сегментах локальной сети.

Сканирование сети посредством DNS

On sait qu’avant de lancer une attaque, les assaillants identifient les cibles, c.-à-d. l'identification des ordinateurs qui seront victimes de l'attaque, ainsi que des ordinateurs permettant l'échange d'informations avec les victimes. Un moyen d'identifier les cibles consiste à interroger le serveur de noms et à obtenir toutes les informations disponibles sur le domaine. Counteraction: pour déterminer une telle analyse, il est nécessaire d'analyser les requêtes DNS (adresse dans le nom) provenant peut-être de serveurs DNS différents, mais pendant une certaine période de temps fixe. Dans le même temps, il est nécessaire de visualiser quelles informations sont transmises et de suivre la recherche d'adresses.

Bombe UDP

Ping balayage balayage du réseau

Ping balayer ou localiser avec ICMP est une méthode efficace.

Contre-action: pour déterminer le fait que les cibles d’analyse ping se trouvent à l’intérieur du sous-réseau, il est nécessaire d’analyser les adresses source et de destination des paquets ICMP.

Balayage de port TCP

Le balayage de port est une méthode bien connue pour reconnaître la configuration de l'ordinateur et les services disponibles. Il existe plusieurs méthodes d'analyse TCP, dont certaines sont appelées furtives, car elles exploitent les vulnérabilités des implémentations de pile TCP / IP dans la plupart des systèmes d'exploitation modernes et ne sont pas détectées par des moyens standard. Contre-action: la contre-action peut être accomplie, par exemple, en envoyant des paquets TCP avec l'indicateur RST défini pour le compte de l'ordinateur en cours d'analyse à l'ordinateur de l'attaquant.

Balayage de port UDP

Un autre type d'analyse de port est basé sur l'utilisation du protocole UDP et se présente comme suit: un paquet UDP adressé au port est transmis à l'ordinateur analysé, dont la disponibilité est contrôlée. Si le port est indisponible, le message ICMP devient indisponible (port de destination inaccessible), sinon il n'y a pas de réponse. Ce type d'analyse est assez efficace. Il vous permet d'analyser tous les ports de l'ordinateur victime en peu de temps. Contre-action: il est possible d'empêcher ce type d'analyse en envoyant des messages sur l'inaccessibilité du port à l'ordinateur de l'attaquant.

Balayage furtif

La méthode est basée sur un code réseau incorrect, vous ne pouvez donc pas garantir qu'il fonctionnera normalement dans une situation donnée. Les paquets TCP avec les indicateurs ACK et FIN installés sont utilisés. Ils devraient être utilisés parce que si un tel paquet est envoyé au port avec une connexion non ouverte, renvoyez toujours le paquet avec l'indicateur RST. Plusieurs méthodes utilisent ce principe: • Envoyer un package FIN. Si l'hôte destinataire renvoie un RST, le port est inactif. Si le RST n'est pas renvoyé, le port est actif. Cette méthode fonctionne dans la plupart des systèmes d'exploitation. • Envoyer un paquet ACK. Si la durée de vie des paquets renvoyés est inférieure à celle des autres paquets RST reçus, ou si la taille de la fenêtre est supérieure à zéro, le port est probablement actif.

Analyse passive

Les cybercriminels ont souvent recours à l'analyse pour déterminer les ports TCP sur lesquels les démons répondent aux demandes du réseau. Un programme d'analyse régulier ouvre les connexions à différents ports en séquence. Dans le cas où la connexion est établie, le programme la réinitialise en indiquant le numéro de port de l'attaquant. Cette méthode est facilement détectée par les messages des démons, surprise par une connexion instantanément interrompue après l’installation ou à l’aide de programmes spéciaux. Les meilleurs de ces programmes ont quelques tentatives pour introduire des éléments d'un élément artificiel dans les tentatives de suivi pour se connecter à différents ports. Toutefois, l’attaquant peut utiliser une autre méthode, le scan passif (en anglais «passive scan»). Lorsqu'il est utilisé, l'attaquant envoie un paquet TCP / IP SYN à tous les ports d'une ligne (ou selon un algorithme donné). Pour les ports TCP acceptant les connexions de l'extérieur, un paquet SYN / ACK sera renvoyé en tant qu'invitation à poursuivre la négociation à trois. Le reste retournera les paquets RST. Après avoir analysé les données de réponse, un attaquant peut rapidement comprendre les ports sur lesquels le programme est exécuté. En réponse aux paquets SYN / ACK, il peut également répondre avec des paquets RST, indiquant que le processus d'établissement de la connexion ne se poursuivra pas (dans le cas général, les paquets RST répondront automatiquement à l'implémentation TCP / IP de l'attaquant s'il ne prend pas de mesures spéciales). La méthode n'est pas détectée par les méthodes précédentes, car la vraie connexion TCP / IP n'est pas établie. Cependant (en fonction du comportement de l'attaquant), vous pouvez suivre le nombre considérablement accru de sessions se trouvant dans l'état SYN_RECEIVED. (à condition que l'attaquant n'envoie pas de RST en réponse) recevant du client un paquet RST en réponse à un SYN / ACK. Malheureusement, avec un comportement suffisamment intelligent de l'attaquant (par exemple, analyser à faible vitesse ou ne contrôler que des ports spécifiques), il est impossible de détecter l'analyse passive, car elle ne diffère pas des tentatives habituelles d'établissement de connexion. En défense, vous ne pouvez que conseiller de fermer tous les services du pare-feu, dont l'accès n'est pas requis de l'extérieur.

Le système d'invitation et le danger des informations qu'il contient

Il est nécessaire de supprimer les "invites système" affichées par les ordinateurs centraux sur les terminaux d'accès à distance pour que l'utilisateur puisse se connecter au système. Cette exigence est due aux raisons suivantes: • L’invite système contient généralement des informations permettant à l’intrus d’identifier le type et la version du système d’exploitation de l’ordinateur central, le type de logiciel d’accès à distance, etc. Ces informations peuvent considérablement simplifier la tâche d'accès au système, car l'intrus peut utiliser des outils d'accès illégal qui exploitent les faiblesses d'un système particulier; • "système d'invitation" indique généralement l'affiliation du système au département. Dans le cas où le système appartient à une agence secrète ou à une structure financière, les intérêts du délinquant peuvent augmenter considérablement; • Un récent procès a abouti à l’abandon d’une action en justice contre une personne ayant pénétré illégalement dans le réseau de la société, qui avait expliqué son comportement en inscrivant son inscription sur le terminal d’accès à distance «Bienvenue à…» sur l’ordinateur central.

Quelques conseils pour la recherche en réseau

• Recherchez les ports et les services ouverts sur le serveur. • Essayez de vous connecter au serveur en tant que IUSR_ <nom de l'ordinateur avec des balles>. • Essayez d'encapsuler SAM._ à partir de / REPAIR (les mots de passe SAM sont obtenus à l'aide de la commande de développement). • Comme beaucoup de gens le savent probablement, les répertoires / scripts et / cgi-bin peuvent exécuter tous les fichiers de ces répertoires dans NT. Vous devez donc fermer l'accès à ces répertoires. Le lancement est effectué à l'aide de la commande suivante (si le fichier exécutable de / scripts) à partir du navigateur est http: //www.idahonews/scripts/getadmin.exe? Test. Vous pouvez obtenir les droits d'administrateur comme suit: les programmes à partir de / scripts ne sont pas lancés sous le nom d'utilisateur de l'utilisateur, mais à partir du même compte Web, à partir duquel on peut conclure que les mots de passe d'administrateur peuvent être facilement supprimés du registre à l'aide de PWDUMP.exe. • Rappelez-vous que les programmes de / SCRIPTS sont exécutés sous le compte Web et non sous le compte de l'utilisateur qui commence. Par conséquent, vous pouvez essayer de réinitialiser les mots de passe du registre à l'aide de PWDUMP.EXE. Les mots de passe seront cryptés. Dans ce cas, vous devez enregistrer la page en tant que fichier texte et essayer de décoder les mots de passe à l'aide du programme BRUTEFORCE. • Sous le compte administrateur, vous pouvez modifier les alias sur ftp et http.

Quelques autres moyens d'obtenir des informations.

• En utilisant whois ou NSLookUp pour trouver d'autres noms, déterminez à qui appartient le réseau. Rappelez-vous la plage d'adresses IP pour une analyse ultérieure. • Allez au routeur le plus proche et trouvez quelque chose. Pour trouver le routeur, vous devez acheminer le chemin vers n'importe quelle adresse IP de la plage détectée. Le routeur le plus proche est déterminé par le temps de réponse. • Essayez de vous connecter au routeur par telnet. • Lancez le scanner de la plage d'adresses IP pour détecter les services en cours d'exécution sur le PC.

Trous et erreurs d'administration dans Windows NT

• Envisagez une vulnérabilité associée à une erreur dans la mise en œuvre du système. Cette vulnérabilité mène à une capacité d'attaque appelée GetAdmin . Vulnérable est le service système NtAddAtom, qui ne vérifie pas les paramètres qui lui sont transmis et définit le bit 0 sur NtGlobalFlag + 2. Pour cela, ouvrez le fichier ntoskrnl.exe et recherchez le point d'entrée sur NtAddAtom. La définition de ce bit désactive la vérification des privilèges du débogueur dans NtOpenProcess et NtOpenThread. Ainsi, tout utilisateur a le droit d'ouvrir n'importe quel processus du système. L’attaque ouvre le processus Winlogon et y intègre des dll. Étant donné que ce service dispose des privilèges de SYSTEM, il peut ajouter un utilisateur au groupe d'administrateurs ou le supprimer de ce groupe. Théoriquement, il existe d'autres failles de sécurité possibles. • L'une des méthodes de pénétration populaires dans le système consiste à deviner le mot de passe. Pour lutter contre cela, il est généralement configuré pour bloquer un compte d'utilisateur après un certain nombre de tentatives de connexion infructueuses. Le compte admin est une exception agréable. Et s'il a accès à l'entrée via le réseau, cela ouvre une échappatoire pour pouvoir deviner le mot de passe. Pour la protection, il est recommandé de renommer l'utilisateur administrateur, de verrouiller le compte, d'interdire à l'administrateur de se connecter via le réseau, d'interdire le transfert de paquets SMB via TCP / IP (ports 137, 138, 139) et de mettre en place une journalisation des entrées ayant échoué.

Spam

Les spammeurs trouveront non seulement un fournisseur de services Internet, mais, le plus probablement, choisiront une société, Il est plus facile pour le fournisseur d’internet de comprendre ce qui s’est passé et il pourra probablement se débarrasser de ces messages plus rapidement. Les spams récurrents peuvent perturber les utilisateurs légitimes en raison d'une surcharge du serveur de messagerie. Le problème est que la connexion à un serveur SMTP n'est pas si difficile. Pour ce faire, vous devez savoir que seules 7 à 8 commandes au serveur SMTP ont commencé à distribuer vos messages. Pour vous protéger contre cela, vous pouvez vérifier les adresses des messages entrants dans la base de données des utilisateurs de serveur enregistrés. Si l'adresse de la personne qui envoie le message ou l'une des adresses demandées par celle-ci ne figure pas dans la liste, aucun courrier électronique ne sera transmis.

Comment protéger le système de messagerie contre les spammeurs

• Si vous ne lisez pas les journaux, les spammeurs agissent en toute impunité. • Programmez tous les serveurs de messagerie de votre entreprise, sauf un, afin qu'ils ne répondent pas à la demande de transfert de message. Le serveur restant doit soigneusement filtrer les adresses IP. • Gardez tous les serveurs de messagerie pouvant recevoir des demandes de transfert de messages à portée de votre pare-feu.

Comment fonctionnent les spammeurs

• Cible sélectionnée - le polluposteur sélectionne de manière aléatoire le nom de domaine de la société, puis détermine le nom d'hôte du fournisseur de service de messagerie SMTP. Si le serveur accepte le courrier, le polluposteur lui demande de diffuser le message par liste d'adresses. • Le serveur exécute la demande en donnant l'impression que les messages quittent l'adresse IP de la victime.

Trous IIS, WWW, FTP

• L'expéditeur peut laisser sa fausse adresse de la manière suivante: il peut se connecter au port SMTP de la machine pour le compte duquel il souhaite envoyer la lettre et entrer le texte de la lettre. • Le service FTP vous permet d'établir des connexions passives en fonction de l'adresse du port spécifié par le client. Cela peut être utilisé par un attaquant pour envoyer des commandes dangereuses au service FTP. Le registre contient la clé: <HKLM \ System \ CurrentControlSet \ Services \ MSFTPSVC \ Parameters> avec la valeur <EnablePortAttack: REG_DWORD:> Assurez-vous que la valeur est définie sur "0" et non sur "1". • Si vous vous connectez via telnet au port 80, la commande "GET ../ .." entraînera un crash de IIS et le message "L'application, exe \ inetinfo.dbg, a généré un message d'erreur d'application à l'adresse 53984655. • Address 'http://www.domain.com/scripts .. \ .. \ scriptname "vous permet d'exécuter le script spécifié. La valeur par défaut est l'invité ou IUSR_WWW est autorisé à lire tous les fichiers de tous les répertoires. Ainsi, ces fichiers peuvent être visualisés, téléchargés et lancés. • Les répertoires \ script \ cgi-bin doivent être fermés, car À partir de ces répertoires, vous pouvez exécuter tous les fichiers directement à partir de la fenêtre du navigateur. • À la demande d'IIS pour une URL très longue (4 à 8 Ko), le serveur se bloque et ne répond pas aux demandes suivantes. Le problème est que la taille exacte de l'URL dépend du serveur spécifique. Par conséquent, les programmes les plus meurtriers, commençant par une certaine taille de base des requêtes et augmentant progressivement la taille, tentent de trouver le point critique qui suspendra le serveur. • Les utilisateurs d'Outlook Express 98 doivent prendre en compte le fait que cette messagerie permet le traitement, y compris pour l'exécution, des scripts Visual-Basic pouvant être facilement masqués dans la lettre. Un tel script a un accès complet au système de fichiers. La véritable protection ne peut être que de définir le "niveau de sécurité" dans Outlook sur "maximum". • Si les balises HTML sont autorisées dans la discussion, personne ne s'immiscera dans l'insertion de quelque chose comme <img src = "http://www.mysite.com/cgi-bin/sniffer.cgi"> dans votre message. En conséquence, toutes les personnes présentes dans le chat (même pas enregistrées) appellent, sans le savoir, le script. • Limitez l'accès au port 25 à certains utilisateurs uniquement.