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

Les attaques réseau et autre chose

Introduction aux attaques réseau

Brèves descriptions des attaques réseau

Fragmentation des données

Transmission de paquets IP fragmentés

Ping attaque d'inondation

PingOfDeath ou SSPing

Bombe UDP

SYN inondation

Protocoles non standard encapsulés dans IP

Utiliser TFTP

Attaque Smurf

Attaque Terre

Introduction à l'Internet d'un faux serveur en créant une "tempête" dirigée de fausses réponses DNS à l'hôte attaqué

L'introduction d'un faux serveur dans Internet en interceptant une requête DNS ou en créant une "tempête" dirigée de fausses réponses DNS vers le serveur DNS attaqué

Introduction d'un faux serveur DNS dans Internet en interceptant une requête DNS

Attaque par inondation DNS

Attaque de spoofing DNS

Attaque d'usurpation IP

Imposition de paquet

Renifler - écouter la chaîne (possible uniquement dans le segment LAN)

Interception de paquets sur le routeur

Imposer un hôte de route faux avec ICMP

WinNuke

Faux serveur ARP

Prédiction TCP numéro de séquence (IP-spoofing)

Tempête locale

Piratage IP

Détection et protection contre les attaques

Méthodes d'analyse

En utilisant le protocole ARP

Analyse du réseau via DNS

Bombe UDP

Analyse des ports TCP

Analyse des ports UDP

Stealth-scan

Scan passif

Invitation du système et danger de l'information qui y est contenue

Quelques conseils pour la recherche en réseau

Quelques autres moyens d'obtenir des informations

Trous et erreurs administratives dans Windows NT

Spamming

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

Comment fonctionnent les spammeurs

Trous IIS, WWW, FTP

Introduction aux attaques réseau

L'intérêt accru pour les réseaux TCP / IP est dû à la croissance rapide d'Internet. Cependant, cela fait réfléchir à la façon de protéger ses ressources d'information contre les attaques du réseau externe. Si vous êtes connecté à Internet, votre système peut être attaqué. Les protocoles de la famille IP sont à la base de la construction de réseaux intranet et de l'Internet mondial. Bien que le développement du TCP / IP ait été financé par le département de la Défense des États-Unis, le protocole TCP / IP n'a pas une sécurité absolue et permet les différents types d'attaques abordés dans ce chapitre. Pour mettre en œuvre de telles attaques, un attaquant potentiel doit avoir le contrôle d'au moins un des systèmes connectés à Internet. L'une des approches pour analyser les menaces à la sécurité des systèmes informatiques consiste à les isoler en une classe distincte de menaces inhérentes uniquement aux réseaux informatiques. Cette classe de menaces est appelée la classe des attaques à distance. Cette approche de la classification semble admissible en raison des caractéristiques fondamentales de la construction de systèmes d'exploitation en réseau. La principale caractéristique de tout système d'exploitation réseau est que ses composants sont distribués dans l'espace et que la connexion entre eux est physiquement effectuée au moyen de connexions réseau spéciales (câble coaxial, paire torsadée, fibre, etc.) et programmée au moyen du mécanisme de message. Dans ce cas, tous les messages de contrôle et les données envoyées par un composant du système d'exploitation réseau à un autre composant sont transmis sur des connexions réseau sous forme de paquets d'échange. Cette caractéristique est la principale raison de l'émergence d'une nouvelle classe de menaces - les attaques à distance. Pour ce type d'attaque, l'attaquant interagit avec le destinataire de l'information, 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 à mettre en œuvre, mais pour un bon programmeur, il n'est pas difficile de mettre en œuvre la boîte à outils appropriée. La possibilité de créer des paquets IP arbitraires est un point clé pour mener des attaques actives. Les attaques à distance peuvent être classées en fonction du type d'action: active ou passive. 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 réseau ou tente de "faire semblant" par un autre système. Dans le second cas, le protocole TCP / IP est utilisé pour mettre le système victime dans un état inopérable. Avec les attaques passives, les attaquants ne se détectent en aucune façon et n'interagissent pas directement avec les 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é réseau. L'idée de détecter une attaque est simple: toute attaque correspond à un certain trafic réseau, par conséquent, l'analyse du trafic vous permet de déterminer l'attaque et de détecter les "traces" de l'attaquant, c'est-à-dire. Identifiez les adresses IP à partir desquelles l'effet d'information a été effectué. Ainsi, la détection des attaques est réalisée par la méthode de surveillance des flux d'information, qui est réalisée en analysant le trafic réseau.

Brèves descriptions des attaques réseau

Il faut se rappeler que les méthodes grossières telles que le ping de gros paquets ou l'inondation SYN peuvent inonder n'importe quelle machine ou sous-réseau Internet, quelle que soit la configuration.

Fragmentation des données

Lors de la transmission d'un paquet de données IP sur un réseau, ce paquet peut être divisé en plusieurs fragments. Plus tard, lorsque le destinataire atteint l'adresse, le paquet est restauré à partir de ces fragments. Un attaquant peut lancer l'envoi d'un grand nombre de fragments, ce qui entraîne un débordement des tampons de programme du côté réception et, dans certains cas, une fin anormale du système.

Transmission de paquets IP fragmentés d'un volume total supérieur à 64 Ko

Le nombre d'implémentations d'attaques exploitant la possibilité de fragmentation des paquets IP est assez important. Plusieurs paquets IP fragmentés sont transmis à la machine victime, qui, une fois assemblés, forment un paquet supérieur à 64 Ko (la taille maximale du paquet IP est 64 Ko moins la longueur de l'en-tête). Cette attaque était efficace contre les ordinateurs exécutant Windows. Lorsque vous recevez un tel package, Windows NT, qui ne dispose pas d'un correctif icmp-fix spécial, "se bloque" ou se bloque. D'autres variantes de telles attaques utilisent des décalages incorrects dans les fragments IP, ce qui entraîne une allocation incorrecte de la mémoire, un débordement des tampons et, éventuellement, des défaillances du système.

Counteraction: pour détecter de telles attaques, il est nécessaire d'effectuer et d'analyser la construction de paquets «à la volée», ce qui augmentera considérablement les besoins en matériel.

Ping attaque d'inondation

Il est apparu parce que le programme "ping", conçu pour évaluer la qualité de la ligne, a la clé pour des tests "agressifs". Dans ce mode, les demandes sont envoyées à la vitesse la plus élevée possible et le programme vous permet d'évaluer comment le réseau fonctionne à la charge maximale. Cette attaque nécessite un attaquant pour accéder aux canaux rapides sur Internet. Rappelez-vous comment ping fonctionne. Le programme envoie un paquet ICMP de type ECHO REQUEST, exposant l'heure et son identifiant. Le cœur de la machine de destination répond à une requête similaire avec le package ICMP ECHO REPLY. Après l'avoir reçu, ping donne la vitesse du paquet. Dans le mode de fonctionnement standard, les paquets sont envoyés après des intervalles de temps, pratiquement sans charger le réseau. Mais dans le mode "agressif", le flux de paquets de requête / réponse d'écho ICMP peut surcharger une petite ligne, ce qui la prive de la possibilité de transmettre des informations utiles. Naturellement, le cas de ping est un cas particulier d'une situation plus générale, liée à la surcharge des canaux. Par exemple, un attaquant peut envoyer plusieurs paquets UDP au port 19 d'une machine victime, et s'il suit les règles généralement acceptées, il a 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 forger l'adresse inverse de tels paquets, ce qui rend difficile de le détecter. Track il aidera à moins que le travail coordonné des spécialistes sur les routeurs intermédiaires, ce qui est presque impossible. Une variante de l'attaque consiste à envoyer des paquets de requête d'écho ICMP avec l'adresse source indiquant à la victime de diffuser des adresses de grands réseaux. En conséquence, chacune des machines répondra à cette fausse requête, et l'expéditeur recevra plus de réponses. En envoyant beaucoup de demandes d'écho de diffusion au nom de la "victime" aux adresses de diffusion de grands réseaux, vous pouvez provoquer un remplissage aigu du canal "victime". Les signes d'inondation sont une charge fortement accrue sur le réseau (ou canal) et une augmentation du nombre de paquets spécifiques (tels que ICMP). En guise de protection, vous pouvez recommander de configurer des routeurs, dans lesquels ils vont filtrer le même trafic ICMP, dépassant une certaine valeur prédéfinie (paquets / unité de temps). Pour vous assurer que vos machines ne peuvent pas servir de source de ping flood, limitez l'accès à ping.

PingOfDeath ou SSPing

Son essence est la suivante: un paquet ICMP gravement fragmenté d'une grande taille (64 Ko) est envoyé à la machine de la victime. La réponse des systèmes Windows pour recevoir un tel paquet est l'affaissement inconditionnel, y compris la souris et le clavier. Le programme de l'attaque est largement disponible sur le réseau sous la forme de code source en C et en tant que fichiers exécutables pour certaines versions d'Unix. Curieusement, contrairement à WinNuke, une victime d'une telle attaque peut être non seulement des machines Windows, MacOS et certaines versions d'Unix sont affectées. Les avantages de cette méthode d'attaque sont généralement que le pare-feu transmet des paquets ICMP, et si le pare-feu est configuré pour filtrer les adresses des expéditeurs, puis en utilisant des techniques d'usurpation simples, vous pouvez tromper un tel pare-feu. L'inconvénient de PingOfDeath est que pour une attaque, il est nécessaire d'envoyer plus de 64 Ko sur le réseau, ce qui ne le rend généralement pas très utile pour les dérivations à grande échelle.

Bombe UDP

Le paquet UDP transmis contient un format invalide pour les champs de service. Certaines versions plus anciennes du logiciel réseau entraînent la réception d'un paquet similaire pour bloquer le système.

SYN inondation

L'inondation avec des paquets SYN est la manière la plus connue de "marteler" un canal d'information. Rappelez-vous comment TCP / IP fonctionne dans le cas de connexions entrantes. Le système répond au paquet C-SYN entrant avec un paquet S-SYN / C-ACK, transfère la session à l'état SYN_RECEIVED et la met en file d'attente. Si le S-ACK n'arrive pas dans le délai spécifié, la connexion est supprimée de la file d'attente, sinon la connexion est transférée à l'état ESTABLISHED. Considérons le cas où la file d'attente des connexions d'entrée est déjà pleine, et le système reçoit un paquet SYN invitant la connexion à établir. Selon le RFC, il sera ignoré silencieusement. L'inondation avec des paquets SYN est basée sur le dépassement 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 genre est l'attaque contre Panix, le fournisseur new-yorkais. Panix n'a pas travaillé pendant 2 semaines. Dans différents systèmes, le travail avec la file d'attente est implémenté de différentes manières. Ainsi, dans les systèmes BSD, chaque port a sa propre file d'attente avec la taille de 16 éléments. Dans les systèmes SunOS, au contraire, il n'y a pas de séparation et le système a simplement une grande file d'attente générale. Par conséquent, pour bloquer, par exemple, le port WWW sur le BSD, il y a assez de 16 paquets SYN, et pour Solaris 2.5, leur nombre sera beaucoup plus grand. Après un certain temps (selon l'implémentation), le système supprime les requêtes de la file d'attente. Cependant, rien n'empêche un attaquant d'envoyer une nouvelle partie de requêtes. Ainsi, même sur une connexion de 2400 bps, un attaquant peut envoyer toutes les 20 minutes à 20-30 paquets sur le serveur FreeBSD, le supportant dans un état inopérant (bien sûr, cette erreur a été corrigée dans les dernières versions de FreeBSD). Comme d'habitude, un attaquant peut tirer parti d'adresses IP inverses aléatoires 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 dans l'état SYN_RECEIVED, ignorant les tentatives se connecteront à ce port. Comme protection, vous pouvez recommander des patches qui implémentent une file d'attente automatique "prune", par exemple, basée sur l'algorithme Early Random Drop. Pour savoir si votre système est protégé contre l'inondation SYN, contactez le fournisseur du système. Une autre option consiste à configurer le pare-feu de sorte que toutes les connexions TCP / IP entrantes soient installées par le pare-feu lui-même, et seulement après qu'elles soient déplacées à l'intérieur du réseau par la machine spécifiée. Cela vous permettra de limiter l'inondation de syn et de ne pas le manquer dans le réseau. Cette attaque fait référence aux attaques par déni de service, dont le résultat est l'impossibilité de fournir des services. L'attaque est généralement dirigée vers un service spécifique et spécifique, tel que telnet ou ftp. Il consiste à passer les paquets d'établissement de connexion au port correspondant au service attaqué. Lorsque la demande est reçue, le système alloue des ressources pour la nouvelle connexion, puis tente de répondre à la demande (envoyer "SYN-ACK") à une adresse inaccessible. Par défaut, NT versions 3.5-4.0 va essayer de répéter la confirmation 5 fois - après 3, 6, 12, 24 et 48 secondes. Après cela encore 96 secondes, le système peut attendre la réponse, et seulement après cela va libérer les ressources allouées pour la future connexion. La durée totale d'utilisation des ressources est de 189 secondes.

Protocoles non standard encapsulés dans IP

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

Utiliser TFTP

Ce protocole ne contient pas de mécanismes d'authentification, ce qui explique pourquoi il attire les intrus.

Attaque Smurf

L'attaque de smurf consiste en la transmission au réseau de requêtes ICMP de diffusion au nom de l'ordinateur victime. En conséquence, les ordinateurs qui ont reçu de tels paquets de diffusion répondent à l'ordinateur de la victime, ce qui conduit à une diminution significative de la bande passante du canal de communication et, dans certains cas, à l'isolement complet du réseau attaqué. L'attaque de smurf est exceptionnellement efficace et répandue. Counteraction: pour reconnaître cette attaque, vous devez analyser la charge du canal et déterminer les raisons de la diminution de la bande passante.

Attaque Terre

L'attaque terrestre exploite les vulnérabilités des implémentations de la pile TCP / IP dans certains systèmes d'exploitation. Il consiste à transmettre au port ouvert de l'ordinateur victime un paquet TCP avec l'ensemble d'indicateurs SYN, et l'adresse source et le port d'un tel paquet sont respectivement égaux à l'adresse et au port de l'ordinateur attaqué. Cela conduit l'ordinateur victime à essayer d'établir une connexion avec lui-même, ce qui entraîne une augmentation significative de l'utilisation du processeur et peut provoquer un blocage ou un redémarrage. Cette attaque est très efficace sur certains modèles de routeurs de Cisco Systems, et l'application réussie d'une attaque au routeur peut désactiver l'ensemble du réseau de l'organisation. Counteraction: Vous pouvez vous protéger de cette attaque en installant un filtre de paquets entre le réseau interne et Internet, en spécifiant une règle de filtrage, indiquant que vous devez supprimer les paquets provenant d'Internet, mais avec les adresses IP originales des ordinateurs du réseau interne.

Introduction à l'Internet d'un faux serveur en créant une "tempête" dirigée de fausses réponses DNS à l'hôte attaqué

Une autre version de l'attaque à distance visant le service DNS est basée sur le deuxième type d'attaque à distance typique "faux objet BC". Dans ce cas, l'attaquant transmet continuellement une fausse réponse DNS pré-préparée à l'hôte attaqué au nom du serveur DNS réel sans recevoir de requête DNS. En d'autres termes, l'attaquant crée sur Internet une "tempête" dirigée de fausses réponses DNS. Ceci est possible, car généralement un protocole UDP est utilisé pour envoyer une requête DNS, dans laquelle il n'y a aucun moyen d'identification de paquet. Le seul critère pour le système d'exploitation réseau de l'hôte pour la réponse reçue du serveur DNS est, premièrement, la correspondance de l'adresse IP de l'expéditeur de la réponse avec l'adresse IP du serveur DNS, et deuxièmement, le nom DNS a le même nom, comme dans la requête DNS, troisièmement, la réponse DNS doit être envoyée au même port UDP à partir duquel la requête DNS a été envoyée (dans ce cas, c'est le premier problème pour l'attaquant), et quatrièmement, dans le DNS -choisir le champ ID de 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, puisque l'attaquant ne peut 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 prend un ensemble limité de valeurs (1023?), Donc l'attaquant doit simplement agir par simple recherche, en envoyant de fausses réponses à la liste de ports appropriée. À première vue, le deuxième problème peut être un ID de requête DNS à deux octets, mais dans ce cas, il est égal à un ou a une valeur proche de zéro (un ID de requête est incrémenté de 1). Par conséquent, pour effectuer cette attaque à distance, l'attaquant doit sélectionner l'hôte (A) qui l'intéresse, la route à laquelle il doit être modifié pour qu'il passe par un faux serveur, l'hôte de l'attaquant. Ceci est réalisé en transmettant constamment ("storm" dirigé) attaquant de fausses réponses de DNS à l'hôte attaqué du nom du vrai serveur DNS aux ports UDP correspondants. Dans ces fausses réponses DNS, l'adresse IP de l'hôte A est l'adresse IP de l'attaquant. En outre, l'attaque se développe selon le schéma suivant. Une fois que la cible de l'attaque (hôte attaqué) est adressée par nom à l'hôte A , une requête DNS sera envoyée au réseau depuis l'hôte donné, que l'attaquant ne recevra jamais, mais cela n'est pas nécessaire puisque l'hôte recevra immédiatement un faux transmis en permanence Réponse DNS, qui sera perçue par le système d'exploitation de l'hôte attaqué comme une réponse réelle du serveur DNS. L'attaque a eu lieu et maintenant l'hôte attaqué transfèrera tous les paquets destinés à A à l'adresse IP de l'hôte de l'attaquant, qui à son tour les transmettra à A , affectant les informations interceptées selon le schéma "false distributed BC". Considérez le schéma fonctionnel de l'attaque à distance proposée sur le service DNS: • transmission constante de fausses réponses DNS à l'hôte attaquant sur différents ports UDP et, éventuellement, avec des ID différents, au nom de (de l'adresse IP) du serveur DNS réel avec le nom de l'hôte intéressant et sa fausse adresse IP, qui sera est l'adresse IP du faux serveur - l'hôte de l'attaquant; • en cas de réception d'un paquet de l'hôte, changer l'en-tête IP du paquet de son adresse IP à l'adresse IP de l'attaquant et envoyer le paquet au serveur (c'est-à-dire le faux serveur travaille avec le serveur en son nom); • si le paquet est reçu du serveur, changez l'en-tête IP du paquet de son adresse IP à l'adresse IP du faux serveur et envoyez le paquet à l'hôte (pour l'hôte, le faux serveur est le vrai serveur). Ainsi, la mise en œuvre de cette attaque à distance, en utilisant des failles de sécurité dans le service DNS, vous permet de perturber le routage entre deux objets spécifiés depuis n'importe où sur Internet. C'est-à-dire que cette attaque à distance est réalisée de manière intersegmentaire par rapport à l'objectif de l'attaque et menace la sécurité de tout hôte Internet utilisant un service DNS normal.

L'introduction d'un faux serveur dans Internet en interceptant une requête DNS ou en créant une "tempête" dirigée de fausses réponses DNS vers le serveur DNS attaqué

À partir du schéma de recherche DNS distant, si le serveur DNS spécifié dans la requête ne trouve pas de noms dans sa base de données, la requête est envoyée par le serveur à l'un des serveurs DNS racine dont les adresses sont contenues 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 requête, ce qui signifie que le serveur DNS lui-même lance une recherche DNS distante. Par conséquent, rien n'empêche l'attaquant, agissant de la manière décrite dans le paragraphe précédent, de diriger son attaque sur le serveur DNS. C'est-à-dire que la cible de l'attaque ne sera plus l'hôte, mais le serveur DNS et les fausses réponses DNS seront envoyées à l'attaquant au nom du serveur DNS racine sur le serveur DNS attaqué. Il est important de prendre en compte la particularité suivante du fonctionnement du serveur DNS. Pour accélérer le travail, chaque serveur DNS met en cache sa propre table de noms et d'adresses IP des hôtes dans la zone de mémoire. Inclure dans le cache des informations modifiées dynamiquement sur les noms et les adresses IP des hôtes trouvés pendant le fonctionnement du serveur DNS. Autrement dit, si le serveur DNS, ayant reçu la demande, ne trouve pas l'entrée correspondante dans la table de cache, il transmet la réponse au serveur suivant et, ayant reçu une réponse, entre les informations trouvées dans la table de cache en mémoire. Ainsi, lors de la réception de la requête suivante, le serveur DNS n'a plus besoin de procéder à une recherche à distance, puisque les informations nécessaires sont déjà dans sa table de cache. De l'analyse du schéma de recherche DNS distant nouvellement décrit, il devient évident que si un attaquant envoie une réponse DNS fausse (dans le cas d'une "tempête" de fausses réponses les gardera dans une transmission constante) en réponse à une requête du serveur DNS, une entrée correspondante contenant de fausses informations apparaîtra dans la table de cache du serveur et tous les hôtes qui accèdent à ce serveur DNS seront désinformés et l'accès à l'hôte, la route à laquelle l'attaquant a décidé de changer, sera communiqué par l'hôte de l'attaquant par des régimes e "faux objet BC". Et au fil du temps, ces fausses informations, capturées dans le cache du serveur DNS, se propageront aux serveurs DNS voisins de plus haut niveau, et, par conséquent, de plus en plus d'hôtes sur Internet seront mal informés et attaqués. Évidemment, si l'attaquant ne peut pas intercepter la requête DNS du serveur DNS, alors pour implémenter l'attaque, il a besoin d'une "tempête" de fausses réponses DNS dirigées vers le serveur DNS. Dans ce cas, le problème principal suivant se pose, différent du problème de la sélection des ports dans le cas d'une attaque dirigée vers l'hôte. Comme indiqué précédemment, le serveur DNS envoie une requête à un autre serveur DNS et identifie cette requête avec une valeur de deux octets (ID). Cette valeur est incrémentée de un à chaque requête transmise. Vous ne pouvez pas indiquer à l'attaquant la valeur actuelle de l'ID de requête DNS. Par conséquent, rien que la recherche de 2 16 valeurs d'ID possibles pour offrir quelque chose est assez difficile. Mais le problème de l'énumération des ports disparaît, puisque toutes les requêtes DNS sont transmises par le serveur DNS au port 53. Le prochain problème, qui est le prérequis pour cette attaque à distance sur le serveur DNS lorsque la "tempête" des fausses réponses DNS est dirigée, est que l'attaque ne réussira que si le serveur DNS envoie une requête pour rechercher un nom spécifique (qui est contenu dans une fausse réponse DNS). Le serveur DNS envoie cette requête si nécessaire et si nécessaire à l'attaquant s'il reçoit une requête DNS de n'importe quel hôte pour rechercher le nom donné et ce nom n'apparaîtra pas dans la table de cache du serveur DNS. En principe, cette requête peut arriver à tout moment et l'attaquant peut devoir attendre les résultats de l'attaque aussi longtemps que désiré. Cependant, rien n'empêche l'attaquant, sans attendre qui que ce soit, d'envoyer une requête DNS similaire au serveur DNS attaqué et d' inciter le serveur DNS à rechercher le nom spécifié dans la requête. Alors cette attaque est susceptible de réussir presque immédiatement après le début de son implémentation.

Introduction d'un faux serveur DNS dans Internet en interceptant une requête DNS

Dans ce cas, il s'agit d'une attaque à distance basée sur l'attaque à distance standard standard associée à l'attente d'une requête de recherche DNS. Avant de considérer l'algorithme d'attaque pour DNS, vous devez faire attention aux subtilités suivantes dans le travail de ce service. Premièrement, le service DNS fonctionne par défaut 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 aucun moyen d'identification des messages. Pour passer de UDP à TCP, l'administrateur du serveur DNS devra étudier sérieusement la documentation. En outre, cette transition ralentira quelque peu le système car, d'une part, lors de l'utilisation de TCP, une connexion virtuelle est nécessaire et, d'autre part, le système d'exploitation du réseau final envoie d'abord une requête DNS utilisant le protocole UDP. 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 qui doit être prise en compte est que la valeur du champ "port expéditeur" dans le paquet UDP devient 1023 (?) Et augmente ensuite avec chaque requête DNS passée. Troisièmement, la valeur de l'ID de la requête DNS se comporte comme suit. Dans le cas d'une requête DNS envoyée par l'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é que dans le cas de l'envoi d'une requête depuis le shell du shell des systèmes d'exploitation Linux et Windows 95 (par exemple, ftp nic.funet.fi), cette valeur est toujours égale à un. Dans le cas où une requête DNS est transmise par Netscape Navigator, à chaque nouvelle requête, le navigateur lui-même augmente cette valeur de un. Dans le cas où la requête est transmise directement par le serveur DNS, le serveur incrémente cette valeur d'ID de un à chaque nouvelle requête transmise. Toutes ces subtilités sont importantes en cas d'attaque sans interception de la requête DNS. Pour implémenter une attaque en interceptant une requête DNS, l'attaquant doit intercepter la requête DNS, extraire le numéro de port UDP de la requête, la valeur ID double de l'identifiant de requête DNS et le nom souhaité et envoyer une réponse DNS fausse à la requête extraite de la requête DNS UDP-port, dans lequel spécifier comme adresse IP l'adresse IP réelle du faux serveur DNS. À l'avenir, cela interceptera complètement et agira activement sur le schéma «False PBC» sur le trafic entre l'hôte «trompé» et le serveur. Considérons le schéma général du faux serveur DNS: • en attente de la requête DNS; • recevoir une requête DNS en en extrayant les informations nécessaires et en les envoyant à l'hôte d'une fausse réponse DNS, au nom de (à partir de l'adresse IP) du serveur DNS actuel, qui spécifie l'adresse IP du faux serveur DNS; • si le paquet est reçu de l'hôte, changez l'en-tête IP du paquet de son adresse IP en adresse IP du faux serveur DNS et envoyez le paquet au serveur (c'est-à-dire que le faux serveur DNS travaille avec le serveur en son nom); • si le paquet est reçu du serveur, changez l'en-tête IP du paquet de son adresse IP à l'adresse IP du faux serveur DNS et envoyez le paquet à l'hôte (pour l'hôte, le faux serveur DNS est le vrai serveur). Une condition préalable pour cette option est d'intercepter la requête DNS. Ceci n'est possible que si l'attaquant se trouve dans le chemin du trafic principal ou dans le segment du serveur DNS réel. L'accomplissement de l'une de ces conditions de localisation de l'attaquant sur le réseau rend difficile l'implémentation de cette attaque à distance (il est probable que l'attaquant ne pourra pas entrer dans le segment du serveur DNS, et encore plus dans le canal de communication intersegmental). Cependant, si ces conditions sont remplies, il est possible d'effectuer une attaque à distance intersegmentaire sur Internet . Notez que la mise en œuvre pratique de cette attaque à distance a révélé un certain nombre de caractéristiques intéressantes dans le fonctionnement du protocole FTP et dans le mécanisme d'identification des paquets TCP. Dans le cas où un client FTP sur l'hôte connecté à un serveur FTP distant via un faux serveur DNS, il s'est avéré que chaque fois que l'utilisateur a émis une application FTP (par exemple, ls, get, put, etc.), le client FTP produit la commande PORT, qui consistait à transférer au serveur FTP dans le champ de données par paquets TCP les numéros de port et adresses IP du client hôte (il est difficile de trouver une signification particulière dans ces actions - pourquoi chaque adresse IP du client est envoyée au serveur FTP)! Cela a pour conséquence que si le faux serveur DNS ne change pas l'adresse IP transmise dans le champ de données du paquet TCP et envoie ce paquet au serveur FTP de la manière habituelle, le paquet suivant sera transféré par le serveur FTP à l'hôte du client FTP, contournant le faux serveur DNS et, plus intéressant, ce paquet sera perçu comme un paquet normal, et, dans le futur, 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 normal ne fournit aucune authentification supplémentaire pour le client FTP, mais transfère tous les problèmes d'identification des paquets et de connexion à un niveau inférieur - la couche TCP.

Attaque par inondation DNS

L'inondation DNS est une attaque dirigée contre les serveurs de noms Internet. Il consiste en un transfert d'un grand nombre de requêtes DNS et conduit au fait que les utilisateurs n'ont pas accès au service de noms et, par conséquent, à l'incapacité des utilisateurs ordinaires à travailler. Counteraction: pour détecter cette attaque, vous devez analyser la charge du serveur DNS et identifier les sources de requêtes.

Attaque de spoofing DNS

Le résultat de cette attaque est l'imposition d'une correspondance imposée entre l'adresse IP et le nom de domaine dans le cache du serveur DNS. À la suite de cette attaque réussie, tous les utilisateurs DNS dans le 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 avec le même nom de domaine. Cela est dû à la nécessité de sélectionner certains paramètres d'échange DNS. Counteraction: pour détecter une telle attaque, vous devez analyser le contenu du trafic DNS.

Attaque d'usurpation d'adresse IP (syslog)

Un grand nombre d'attaques sur Internet sont associées à la substitution de l'adresse IP source. Ces attaques incluent l'usurpation de syslog, qui consiste à envoyer un message à l'ordinateur de la victime au nom d'un autre ordinateur sur le réseau interne. Étant donné que le protocole syslog est utilisé pour gérer les journaux système, vous pouvez imposer des informations ou masquer l'accès non autorisé à un ordinateur victime en envoyant des faux messages. Counteraction: détection d'attaques liées à la substitution d'adresses IP, il est possible de surveiller la réception sur l'une des interfaces du paquet avec l'adresse source de la même interface ou de surveiller la réception sur l'interface externe de paquets avec adresses IP du réseau interne.

Imposition de paquet

Un attaquant envoie des paquets avec une fausse adresse de retour au réseau. Avec cette attaque, un attaquant peut basculer vers une connexion informatique établie entre d'autres ordinateurs. Dans ce cas, les droits d'accès de l'attaquant deviennent égaux aux droits de l'utilisateur dont la connexion au serveur a été commuté sur l'ordinateur de l'intrus.

Renifler - écouter la chaîne (possible uniquement dans le segment LAN)

Pratiquement toutes les cartes réseau supportent la capacité d'intercepter des paquets transmis sur un canal LAN partagé. Dans ce cas, le poste de travail peut recevoir des paquets adressés à d'autres ordinateurs dans le même segment de réseau. Ainsi, tout échange d'informations dans le segment de réseau devient disponible pour un attaquant. Pour réussir cette attaque, l'ordinateur de l'attaquant doit être situé dans le même segment du réseau local que l'ordinateur attaqué.

Interception de paquets sur le routeur

Le logiciel réseau du routeur a accès à tous les paquets réseau transmis via ce routeur, ce qui vous permet d'intercepter les paquets. Pour mettre en œuvre cette attaque, un attaquant doit avoir un accès privilégié à au moins un routeur réseau. Comme beaucoup de paquets sont habituellement transmis par le routeur, leur interception totale est presque impossible. Cependant, des paquets individuels peuvent être interceptés et sauvegardés pour une analyse ultérieure par l'attaquant. L'interception la plus efficace des paquets FTP contenant des mots de passe utilisateur, ainsi que des e-mails.

Imposer un hôte de route faux avec ICMP

Sur Internet, il existe un protocole ICMP (Internet Control Message Protocol), dont l'une des fonctions consiste à informer les hôtes du changement du routeur actuel. Ce message de contrôle est appelé redirection. Il est possible d'envoyer à partir de n'importe quel hôte du segment de réseau un faux message de redirection au nom du routeur vers l'hôte attaqué. Par conséquent, l'hôte modifie la table de routage actuelle et, à l'avenir, tout le trafic réseau de cet hôte passera, par exemple, via un hôte envoyant un faux message de redirection. Ainsi, il est possible de mettre en œuvre une imposition active d'une fausse route dans un segment d'Internet.

WinNuke

Comme pour les données normales transférées via une connexion TCP, la norme transmet également des données hors bande. Au niveau des paquets TCP, ceci est exprimé dans un pointeur urgent non nul. La plupart des PC avec Windows ont un protocole réseau NetBIOS, qui utilise pour leurs besoins 3 ports IP: 137, 138, 139. En fait, si vous vous connectez à la machine Windows dans 139 ports et y envoyez plusieurs octets de données OutOfBand, l'implémentation de NetBIOS ne sachant pas quoi faire avec ces données, popsto suspendre ou machine perezazgruzhaet. Pour Windows 95, cela ressemble généralement à un écran de texte bleu qui signale une erreur dans le pilote TCP / IP et l'impossibilité de travailler avec le réseau jusqu'à ce que le système d'exploitation redémarre. NT 4.0 sans les Service Packs est remplacé, NT 4.0 avec le deuxième pack série tombe dans l'écran bleu. L'envoi de données similaire à 135 et à certains autres ports entraîne une charge importante du processeur RPCSS.EXE. Sur NTWS cela conduit à un ralentissement significatif, NTS est pratiquement gelé.

Faux serveur ARP

Sur Internet, chaque hôte dispose d'une adresse IP unique, qui reçoit tous les messages du réseau global. Cependant, le protocole IP n'est pas tant un réseau qu'un protocole d'échange inter-réseau destiné à la communication entre objets dans le réseau global. Au niveau de la couche liaison, les paquets sont adressés aux adresses matérielles des cartes réseau. Sur Internet, le protocole ARP (protocole de protocole d'adresse IP) est utilisé pour la correspondance bi-univoque entre les adresses IP et Ethernet. Initialement, l'hôte peut ne pas avoir d'informations sur les adresses Ethernet des autres hôtes qui se trouvent dans le même segment, y compris l'adresse Ethernet du routeur. Par conséquent, lorsque les ressources réseau sont accédées pour la première fois, l'hôte envoie une requête ARP diffusée, qui sera reçue par toutes les stations dans ce segment du réseau. A réception de cette requête, le routeur envoie une réponse ARP à l'hôte demandeur, dans laquelle il signale son adresse Ethernet. Ce schéma de travail permet à un attaquant d'envoyer une fausse réponse ARP dans laquelle se déclarer l'hôte désiré (par exemple, un routeur) et, à l'avenir, de surveiller activement tout le trafic réseau de l'hôte "déçu".

Prédiction TCP numéro de séquence (IP-spoofing)

Dans ce cas, le but de l'attaquant est de prétendre être un autre système que, par exemple, le système victime "fait confiance". La méthode est également utilisée à d'autres fins - par exemple, pour utiliser la victime SMTP pour envoyer de faux emails. La connexion TCP est établie en trois étapes: le client sélectionne et envoie le numéro de séquence (appel C-SYN) au serveur, le serveur envoie au client un paquet de données contenant la confirmation (C-ACK) et le propre numéro de séquence du serveur (S-SYN ). Maintenant, le client doit envoyer une confirmation (S-ACK). Après cela, la connexion est établie et l'échange de données commence. Chaque paquet comporte dans son en-tête un champ 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 de la transmission. Supposons qu'un attaquant puisse prédire quel numéro de séquence (S-SYN par schéma) sera envoyé par le serveur. Il est possible de le faire en fonction de la connaissance de l'implémentation spécifique de TCP / IP. Par exemple, dans BSD 4.3, la valeur du numéro de séquence qui sera utilisée lors de la définition de la valeur suivante augmente chaque seconde de 125 000. Ainsi, en envoyant un paquet au serveur, l'attaquant recevra une réponse et pourra (probablement avec plusieurs tentatives et avec la correction de vitesse) numéro de séquence pour la prochaine connexion. Si l'implémentation TCP / IP utilise un algorithme spécial pour déterminer le numéro de séquence, il peut être déterminé en envoyant plusieurs dizaines de paquets au serveur et en analysant ses réponses. Donc, supposons que le système A fasse confiance au système B, de sorte que l'utilisateur du système B puisse faire "rlogin A" et finir 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, système B et C - dans le rôle des clients. La première tâche de l'attaquant consiste à introduire le système B dans un état où il ne peut pas répondre aux demandes du réseau. Cela peut être fait de plusieurs façons, dans le cas le plus simple, il suffit d'attendre que le système B redémarre. Quelques minutes, au cours desquelles ce sera impraticable, devraient suffire. Après cela, l'attaquant peut essayer de prétendre être le système B, afin d'avoir accès au système A (au moins brièvement). Un attaquant envoie plusieurs paquets IP initiant une 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 indiquée comme adresse de retour. Le système A répond avec un paquet avec un numéro de séquence qui est transmis au système B. Cependant, le système B ne le recevra jamais (il est désactivé), comme, en effet, un attaquant. Il devine sur la base de l'analyse précédente quel numéro de séquence a été envoyé au système B. L'attaquant confirme la réception du paquet de A, envoyant un paquet avec le S-ACK allégué pour le compte de B (notez que si les systèmes sont situés dans le même segment, un attaquant nombre est suffisant pour intercepter le paquet envoyé par le système A). Après cela, si l'attaquant a eu de la chance et que le numéro de séquence du serveur a été deviné correctement, la connexion est considérée comme établie. Maintenant, un attaquant peut envoyer un faux paquet IP, qui contiendra déjà des données. Par exemple, si l'attaque a été dirigée vers rsh, elle peut contenir les commandes permettant de créer le fichier .rhosts ou d'envoyer le fichier / etc / passwd à l'attaquant par e-mail. Counteraction: les paquets avec des adresses internes provenant du monde extérieur serviront de signal d'usurpation IP le plus simple. Le logiciel du routeur peut en informer l'administrateur. Cependant, ne vous faites pas d'illusions: l'attaque peut provenir de votre réseau. Dans le cas de l'utilisation d'outils de surveillance réseau plus intelligents, l'administrateur peut surveiller (en mode automatique) les paquets provenant de systèmes qui sont dans un état inaccessible. Cependant, qu'est-ce qui empêche un intrus d'imiter le fonctionnement du système B en répondant à des paquets ICMP? Quels sont les moyens de se protéger contre l'usurpation d'adresse IP? Premièrement, vous pouvez compliquer ou empêcher de deviner le numéro de séquence (l'élément clé de l'attaque). Par exemple, vous pouvez augmenter le taux de modification du numéro de séquence sur le serveur ou sélectionner une augmentation aléatoire du numéro de séquence (de préférence en utilisant un algorithme cryptographiquement stable 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 lui ajouter des règles selon lesquelles tous les paquets provenant de l'extérieur et ayant des adresses de retour depuis notre espace adresse ne doivent pas entrer dans le réseau. De plus, il est nécessaire de minimiser la confiance des machines entre elles. Idéalement, il ne devrait pas y avoir de moyen d'accéder directement à la machine du réseau voisin, en ayant les droits de superutilisateur sur l'un d'entre eux. Cela ne vous évitera pas d'utiliser des services qui ne nécessitent 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 du flux TCP / IP résout dans le cas général le problème de l'usurpation d'adresse IP (à condition que des algorithmes cryptographiquement stables soient utilisés). Afin de réduire le nombre de ces attaques, il est également recommandé de configurer le pare-feu pour filtrer les paquets envoyés par notre réseau vers l'extérieur, mais ayant des adresses qui n'appartiennent pas à notre espace d'adressage.

Tempête locale

Faisons une petite digression à l'implémentation de TCP / IP et considérons les «tempêtes locales», par exemple les tempêtes UDP. En règle générale, les systèmes UDP supportent le fonctionnement des ports UDP tels que 7 ("echo", le paquet reçu est renvoyé), 19 (le "générateur de caractères", en réponse au paquet reçu, l'expéditeur envoie la chaîne de caractères) et autres (date etc). Dans ce cas, un attaquant peut envoyer un seul paquet UDP, avec 7 comme port source, 19 comme destination, et deux ordinateurs sur votre réseau (ou même 127,0, par exemple). 0,1). Après avoir reçu le paquet, le 19ème port répond avec une chaîne qui arrive au port 7. Le septième port le duplique et le renvoie à 19 .. et ainsi de suite ad infinitum. Un cycle infini dévore les ressources de la machine et ajoute une charge insignifiante au canal. Bien sûr, avec le premier paquet UDP perdu, la tempête cessera. Противодействие: в качестве защиты стоит еще раз порекомендовать не пропускать в сети пакеты с внутренними адресами, но пришедшие извне. Также рекомендуется закрыть на 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 attaquants effectuent l'identification des cibles, c'est-à-dire Identifier les ordinateurs qui seront victimes d'attaques, ainsi que les ordinateurs qui effectuent des échanges d'informations avec les victimes. Une façon d'identifier les cibles consiste à interroger le serveur de noms et à obtenir toutes les informations de domaine disponibles. Counteraction: pour déterminer une telle analyse, vous devez analyser les requêtes DNS (adresse dans le nom) provenant, peut-être, de différents serveurs DNS, mais pendant une certaine période fixe. Dans ce cas, vous devez regarder quelles informations leur sont envoyées et suivre la recherche d'adresses.

Bombe UDP

Analyse d'un réseau à l'aide de la méthode ping sweep

Balayage Ping ou détection de cible en utilisant le protocole ICMP est une méthode efficace.

Contre-mesures: Pour déterminer le fait de l'analyse ping des cibles à l'intérieur du sous-réseau, il est nécessaire d'analyser les adresses source et de destination des paquets ICMP.

Analyse des ports TCP

L'analyse de port est une méthode connue pour reconnaître la configuration d'un ordinateur et les services disponibles. Il existe plusieurs méthodes d'analyse TCP, dont certaines sont appelées furtif, car elles utilisent 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. Counteraction: la contre-action peut être effectuée, par exemple, en transférant des paquets TCP avec l'indicateur RST défini pour le compte de l'ordinateur analysé sur l'ordinateur de l'intrus.

Analyse des ports UDP

Un autre type d'analyse de port est basé sur l'utilisation du protocole UDP et consiste en ce qui suit: un paquet UDP est envoyé à l'ordinateur analysé, adressé au port, dont la disponibilité est vérifiée. Si le port n'est pas disponible, un message ICMP inaccessible arrive en réponse, sinon il n'y a pas de réponse. Ce type de scan est assez efficace. Il vous permet d'analyser tous les ports sur un ordinateur victime dans un court laps de temps. Counteraction: pour contrecarrer ce type d'analyse, il est possible d'envoyer des messages sur l'indisponibilité du port à l'ordinateur de l'attaquant.

Stealth-scan

La méthode est basée sur un code de réseau incorrect, donc vous ne pouvez pas garantir qu'il fonctionnera correctement dans une situation particulière. Les paquets TCP sont utilisés avec les drapeaux ACK et FIN installés. Ils devraient être utilisés, car Si un tel paquet est envoyé au port dans une connexion non ouverte, le paquet avec l'indicateur RST retourne toujours. Il existe plusieurs méthodes qui utilisent ce principe: • Envoyer un paquet FIN. Si l'hôte destinataire renvoie RST, le port est inactif, si RST ne renvoie pas, 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.

Scan passif

L'analyse est souvent utilisée par les pirates pour déterminer quels ports TCP exécutent des démons qui répondent aux demandes du réseau. Un programme de scanner commun ouvre les connexions aux différents ports en série. Dans le cas où la connexion est établie, le programme le réinitialise, en informant le numéro de port de l'attaquant. Cette méthode est facilement détectée par les rapports de démons, surprise instantanément interrompue après l'installation par la connexion, ou en utilisant des programmes spéciaux. Les meilleurs de ces programmes ont quelques tentatives pour introduire des éléments d'un élément artificiel dans le suivi des tentatives de connexion à différents ports. Cependant, un attaquant peut utiliser une autre méthode - l'analyse passive (le terme anglais «passive scan»). Quand il est utilisé, un attaquant envoie un paquet SYN TCP / IP à tous les ports d'une rangée (ou par un algorithme donné). Pour les ports TCP qui acceptent les connexions de l'extérieur, le paquet SYN / ACK sera retourné comme une invitation à poursuivre la prise de contact à trois voies. Le reste renverra des paquets RST. En analysant la réponse donnée, l'attaquant peut rapidement identifier les ports sur lesquels le programme s'exécute. En réponse aux paquets SYN / ACK, il peut également répondre avec des paquets RST, indiquant que le processus d'installation de connexion ne se poursuivra pas (dans le cas général, l'implémentation TCP / IP de l'attaquant répondra automatiquement avec des paquets RST 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 une connexion TCP / IP réelle n'est pas établie. Cependant (en fonction du comportement de l'attaquant), vous pouvez surveiller le nombre considérablement accru de sessions dans l'état SYN_RECEIVED. (à condition que l'attaquant n'envoie pas de RST en réponse) la réception du client paquet RST en réponse au SYN / ACK. Malheureusement, avec un comportement assez intelligent d'un attaquant (par exemple, balayer à faible vitesse ou ne vérifier que des ports spécifiques), il est impossible de détecter un balayage passif, car il n'est pas différent des tentatives habituelles pour établir une connexion. À titre de protection, vous ne pouvez que vous conseiller de fermer tous les services sur le pare-feu, auxquels vous n'avez pas besoin d'accéder depuis l'extérieur.

Invitation du système et danger de l'information qui y est contenue

Il est nécessaire de supprimer les "invites système" affichées par les ordinateurs centraux sur les terminaux d'accès à distance pour se connecter au système. Les «invitations système» contiennent généralement des informations permettant au contrevenant 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. Une telle information peut grandement simplifier la pénétration du système. Utilisez des outils d'accès illégal qui exploitent les faiblesses d'un système particulier; • "invite système" indique généralement la propriété départementale du système. Dans le cas où le système appartient à une agence secrète ou à une structure financière, l'intérêt du délinquant peut augmenter considérablement; • Un procès récent a rejeté le procès de l'entreprise contre une personne qui s'était illégalement infiltrée dans le réseau de l'entreprise, en motivant ses actions par une inscription sur le terminal d'accès à distance à l'ordinateur central "Welcome to ...".

Quelques conseils pour la recherche en réseau

• Scannez le serveur pour les ports et services ouverts. • Essayez de vous connecter au serveur en tant que IUSR_ <nom de machine avec des balles> • Essayez de déverrouiller SAM._ à partir de / REPAIR (les mots de passe de SAM sont obtenus par la commande expand). • Répertoires / scripts et / cgi-bin, comme beaucoup le savent probablement, dans NT, vous pouvez exécuter n'importe quel fichier à partir de ces répertoires, donc vous devriez fermer ces répertoires. Le lancement est effectué par approximativement une telle commande (si le fichier exécutable est dans / scripts) du navigateur - http: //www.idahonews/scripts/getadmin.exe? Test. Vous pouvez obtenir les droits d'administrateur de la façon suivante: les programmes de / scripts sont lancés non pas sous la gestion de l'utilisateur, mais à partir du même compte Web, à partir duquel on peut facilement déduire les mots de passe de l'administrateur à partir du registre PWDUMP.exe. • Il faut se rappeler que les programmes de / SCRIPTS sont démarrés sous le compte Web et non sous le compte de l'utilisateur qui a lancé le programme. Par conséquent, vous pouvez essayer de décrypter les mots de passe du registre en utilisant PWDUMP.EXE. Les mots de passe seront encodé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 remplacer les alias par ftp et http.

Quelques autres moyens d'obtenir des informations

• À l'aide de whois ou NSLookUp pour trouver d'autres noms, découvrez qui possède le réseau. Rappelez-vous la plage d'adresses IP pour leur analyse ultérieure. • Aller au routeur le plus proche et trouver quelque chose. Pour trouver le routeur, vous devez tracer le chemin vers n'importe quelle adresse IP à partir de la plage détectée. Le routeur le plus proche est déterminé par le temps de réponse. Essayez d'aller au routeur telnet'om. • Exécutez l'analyseur de plage d'adresses IP pour détecter les services s'exécutant sur le PC.

Trous et erreurs administratives dans Windows NT

• Considérer la vulnérabilité associée à une erreur dans la mise en œuvre du système. Cette vulnérabilité conduit à la possibilité d'une attaque, appelée GetAdmin . Vulnerable 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 ce faire, ouvrez le fichier ntoskrnl.exe et recherchez le point d'entrée dans 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 dans le système. L'attaque ouvre le processus du processus Winlogon et y incorpore la DLL. Comme ce service a les privilèges SYSTEM, il peut ajouter un utilisateur au groupe Administrateur ou le supprimer de ce groupe. Théoriquement, d'autres violations de la sécurité du système sont possibles. • L'une des méthodes les plus populaires pour entrer dans le système consiste à sélectionner un mot de passe. Pour contrer cela, il est généralement configuré pour verrouiller le compte utilisateur après un certain nombre de tentatives de connexion infructueuses. Une belle exception est le compte administrateur. Et s'il a le droit d'accéder à l'entrée via le réseau, cela ouvre une brèche pour deviner le mot de passe. Pour des raisons de protection, il est recommandé de renommer l'utilisateur administrateur, de verrouiller le compte, d'interdire à l'administrateur de se connecter au réseau, d'empêcher l'envoi de paquets SMB via TCP / IP (ports 137,138,139) et d'enregistrer les entrées ayant échoué.

Spamming

Les spammeurs ne trouveront pas seulement un FAI pour commencer à poster leurs déchets de courrier, mais, très probablement, ils choisiront une société. le fournisseur d'accès à Internet peut plus facilement comprendre ce qui s'est passé, et il sera probablement capable de se débarrasser plus rapidement de ces messages. Périodiquement, le spam peut perturber les utilisateurs légitimes en raison d'une surcharge du serveur de messagerie. Le problème est que ce n'est pas si difficile de se connecter à un serveur SMTP. Pour ce faire, vous devez connaître seulement 7-8 commandes afin que le serveur SMTP distribue vos messages. Pour se prémunir contre cela, vous pouvez vérifier les adresses des messages entrants dans la base de données des utilisateurs enregistrés du serveur. Si l'adresse du message d'envoi ou l'une des adresses demandées par lui ne figure pas dans la liste, l'e-mail ne sera pas transmis.

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

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

Comment fonctionnent les spammeurs

• La cible est sélectionnée - le spammeur sélectionne aléatoirement le nom de domaine de l'entreprise et devine le nom d'hôte du serveur SMTP. Si le serveur accepte le courrier, le spammeur lui demande de distribuer le message à la liste d'adresses. • Le serveur exécute la requête, donnant l'impression que les messages quittent l'adresse IP de la société victime.

Trous IIS, WWW, FTP

• L'expéditeur peut laisser sa fausse adresse comme suit: l'expéditeur peut se connecter au port SMTP de la machine au nom de laquelle il veut envoyer le message et entrer le texte du message. • Le service FTP vous permet d'établir des connexions passives en fonction de l'adresse de port spécifiée par le client. Cela peut être utilisé par un attaquant pour émettre des commandes dangereuses au service FTP. Le registre contient la clé: <HKLM \ System \ CurrentControlSet \ Services \ MSFTPSVC \ Parameters> avec la valeur <EnablePortAttack: REG_DWORD:> Vérifiez 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 l'écrasement de IIS et le message "L'application, exe \ inetinfo.dbg, a généré une erreur d'application." http://www.domain.com/scripts .. \ .. \ scriptname "vous permet d'exécuter le script spécifié. Invité par défaut ou IUSR_WWW a un accès en lecture à tous les fichiers de tous les répertoires. Ainsi, ces fichiers peuvent être consultés, téléchargés et lancés. • Les répertoires \ script \ cgi-bin doivent être fermés. à partir de ces répertoires, vous pouvez exécuter des fichiers directement à partir de la fenêtre du navigateur. • Lorsque IIS a une URL très longue (4 à 8 Ko), le serveur se bloque et ne répond plus à d'autres demandes. Le problème est que la taille exacte de l'URL dépend du serveur particulier, donc les programmes de tueur commençant par une taille de requête de base et augmentant progressivement la taille essaient de trouver ce point critique qui va bloquer le port-serveur. • Les utilisateurs d'Outlook Express 98 doivent prendre en compte le fait que ce mailer permet de traiter, y compris l'exécution, des scripts Visual Basic qui peuvent être facilement cachés dans le courrier électronique. Un script similaire a un accès complet au système de fichiers. La protection réelle ne peut devenir l'installation d'un «niveau de sécurité» dans Outlook à «maximum». • Si vous autorisez la saisie de balises html dans le salon de discussion, personne n'interférera dans l'insertion de quelque chose comme <img src = "http://www.monsite.com/cgi-bin/sniffer.cgi"> dans votre message. En conséquence, tous ceux présents dans le chat (même pas enregistrés) vont, sans le savoir, appeler le script. • Restreindre l'accès au port 25 uniquement pour certains utilisateurs.