Особенности работы протоколов.
Особенности работы протоколов.
Более интересными средствами являются методы, основанные на анализе особенностей работы той или иной службы. Суть этих методов состоит в посылке запросов, которые немного отличаются от стандарта, в использовании редких (малоизвестных) команд или опций. Для начала рассмотрим одну из самых распространенных сетевых служб - электронную почту. Сейчас практически в любой организации есть свой SMTP-сервер, так что пример будет очень актуален.
SMTP-сервер.
Поведение SMTP-сервера определяют несколько стандартов: RFC 821, RFC 1425, RFC 1985. Эти стандарты определяют команды, которые SMTP-клиент может выполнить, подключившись к серверу, обязательные возможности самого сервера, допустимые аргументы и данные. Однако, как обычно, не все реализации серверов SMTP удовлетворяют этим требованиям. Кроме того, анализу подлежат и сообщения об ошибках, выдаваемые сервером SMTP, хотя эти сообщения могут быть изменены администратором сервера, что снижает достоверность данного метода. Как правило, достаточно кода ошибки. Рассмотрим несколько приемов, позволяющих отличить один SMTP-сервер от другого.
Как известно, при установлении SMTP-сессии необходимо указать сначала команду HELO, потом MAIL FROM. В случае если MAIL FROM идет сразу, без HELO, некоторые серверы позволяют такое соединение (возвращая код ошибки 220), другие запрещают (501 или 503).
Также стандарты требуют указания имени домена вместе с командой HELO. Стандарт этого не разрешает, но некоторые серверы позволяют выполнить эту команду без указания домена.
Использование команды MAIL FROM <имя> без указания символа «:* полю FROM. Некоторые серверы позволяют это, хотя стандарт это явно запрещает.
Использование команды MAIL FROM: <> с пустым адресом отправителя. Все серверы должны эта разрешать, но бывают исключения.
Некорректное задание адреса отправителя в команде МАIL FROM. Некоторые серверы это запрещают, то есть проверяют существование указанного домена.
Еще один распространенный метод идентификации сервера SMTP - проверка поддержки некоторых команд:
HELP
VRFY
EXPN
TURN
SOML
NOOP
ЕНLО
Еще одна интересная техника - «mail-bouncing». Она слабо распространена из-за достаточно большой сложности и малой скорости работы. Смысл этой техники заключается в анализе заголовков электронных писем, специально составленных и посланных в исследуемую сеть. Так, интерес представляют письма для несуществующих пользователей, поскольку они возвращают уведомления о невозможности доставки (правда, далеко не всегда). В этих уведомлениях содержится некоторая информация о почтовых серверах, участвующих в процессе доставки письма. На основе нескольких таких «писем-бумерангов» можно узнать некоторое число узлов внутренней сети (не имея к ней непосредственного доступа) и топологию почтовых пересылок. Кроме того, почтовый протокол позволяет отправлять письма с явным указанием нескольких промежуточных пунктов пересылки. Это дает возможность создать письмо, которое, проделав заданный маршрут внутри исследуемой сети, вернется к отправителю (все это, конечно, существенно зависит от настроек почтовых серверов).
Собранная таким образом информация о сети должна быть подвергнута сравнительному анализу с результатами социальной инженерии, о которой я уже упоминал ранее. Располагая сведениями, полученными с помощью социальной инженерии, о том, какой почтовый сервер используется, исследователь сети может сравнить это с теми данными, которые были получены техническими средствами. Считая, что результаты социальной инженерии более точные и правдивые, мы сравниваем их с информацией о почтовом сервере. В случае если сведения, полученные из обоих источников, совпадают, мы можем сделать вывод о том, что технические средства исследования не пытаются обмануть, и больше доверять информации, полученной данным способом.
Веб-сервер.
Еще одна важная служба прикладного уровня - НТТР. Протокол НТТР версии 1.l описан в RFC 2068. В этом документе предусмотрен метод OPTIONS, согласно которому НТТР-сервер возвращает развернутую информацию о себе.
Например:
OPTIONS "HTTP\I.1.
Собственно, примеры таких ответов я уже приводил ранее, когда описывал анализ «баннеров».
Петухов Олег, юрист в области международного права и защиты персональных данных, специалист в области информационной безопасности, защиты информации и персональных данных.
Телеграм-канал: https://t.me/zashchitainformacii
Группа в Телеграм: https://t.me/zashchitainformacii1
Сайт: https://legascom.ru
Электронная почта: online@legascom.ru
#защитаинформации #информационнаябезопасность
Protocol operation features.
More interesting tools are methods based on an analysis of the specifics of a particular service. The essence of these methods is to send requests that differ slightly from the standard, and to use rare (little-known) commands or options. First, let's look at one of the most common online services - email. Now almost every organization has its own SMTP server, so the example will be very relevant.
SMTP server.
SMTP server behavior is defined by several standards: RFC 821, RFC 1425, RFC 1985. These standards define the commands that the SMTP client can execute by connecting to the server, the required capabilities of the server itself, and acceptable arguments and data. However, as usual, not all SMTP server implementations meet these requirements. In addition, the SMTP server error messages are subject to analysis, although these messages can be changed by the server administrator, which reduces the reliability of this method. As a rule, an error code is sufficient. Let's look at several techniques to distinguish one SMTP server from another.
As you know, when establishing an SMTP session, you must first specify the HELO command, then MAIL FROM. If MAIL FROM goes immediately, without HELO, some servers allow such a connection (returning error code 220), others prohibit it (501 or 503).
The standards also require specifying the domain name along with the HELO command. The standard does not allow this, but some servers allow you to run this command without specifying the domain.
Using the MAIL FROM <name> command without specifying the ":* the FROM field. Some servers allow this, although the standard explicitly prohibits it.
Using the MAIL FROM: <> command with an empty sender's address. All servers must allow this, but there are exceptions.
Incorrect setting of the sender's address in the MAIL FROM command. Some servers prohibit this, that is, they verify the existence of the specified domain.
Another common method of SMTP server identification is to verify the support of certain commands:
HELP
VRFY
EXPN
TURN
SOML
NOOP
ENLO
Another interesting technique is "mail-bouncing". It is poorly distributed due to its rather high complexity and low speed of operation. The purpose of this technique is to analyze the headers of emails specially compiled and sent to the network under study. So, letters for non-existent users are of interest, since they return notifications about the impossibility of delivery (although not always). These notifications contain some information about the mail servers involved in the email delivery process. Based on several such "boomerang letters", you can find out a certain number of nodes in the internal network (without having direct access to it) and the topology of mail shipments. In addition, the mail protocol allows you to send emails with explicit indication of several intermediate forwarding points. This makes it possible to create an email that, after completing a set route within the network under study, will return to the sender (all this, of course, depends significantly on the settings of the mail servers).
The information collected in this way about the network should be subjected to a comparative analysis with the results of social engineering, which I mentioned earlier. With the information obtained through social engineering about which mail server is being used, the network researcher can compare this with the data that was obtained by technical means. Considering that the results of social engineering are more accurate and truthful, we compare them with information about the mail server. If the information obtained from both sources is the same, we can conclude that the technical means of research are not trying to deceive, and we can trust the information obtained in this way more.
The web server.
Another important application layer service is NTTP. The HTTP protocol version 1.l is described in RFC 2068. This document provides the OPTIONS method, according to which the HTTP server returns detailed information about itself.
For example:
OPTIONS "HTTP\I.1.
Actually, I have already given examples of such answers earlier, when I described the analysis of "banners".
Oleg Petukhov, lawyer in the field of international law and personal data protection, information security specialist security, protection of information and personal data.
Telegram channel: https://t.me/protectioninformation
Telegram Group: https://t.me/informationprotection1
Website: https://legascom.ru
Email: online@legascom.ru
#informationprotection #informationsecurity
Merkmale der Arbeit der Protokolle.
Interessantere Mittel sind Methoden, die auf der Analyse der Merkmale eines bestimmten Dienstes basieren. Das Wesen dieser Methoden besteht darin, Anfragen zu senden, die sich geringfügig vom Standard unterscheiden, indem Sie seltene (wenig bekannte) Befehle oder Optionen verwenden. Betrachten wir zunächst einen der gängigsten Netzwerkdienste - E-Mail. Jetzt hat fast jede Organisation einen eigenen SMTP-Server, so dass das Beispiel sehr relevant sein wird.
SMTP-Server.
Das Verhalten eines SMTP-Servers wird von mehreren Standards definiert: RFC 821, RFC 1425, RFC 1985. Diese Standards definieren die Befehle, die ein SMTP-Client ausführen kann, wenn er eine Verbindung zum Server herstellt, die erforderlichen Funktionen des Servers selbst, gültige Argumente und Daten. Wie üblich erfüllen jedoch nicht alle SMTP-Serverimplementierungen diese Anforderungen. Außerdem werden die vom SMTP-Server ausgegebenen Fehlermeldungen analysiert, obwohl diese Nachrichten vom Serveradministrator geändert werden können, was die Zuverlässigkeit dieser Methode beeinträchtigt. Im Allgemeinen reicht ein Fehlercode aus. Betrachten Sie einige Techniken, mit denen Sie einen SMTP-Server von einem anderen unterscheiden können.
Wie Sie wissen, müssen Sie beim Einrichten einer SMTP-Sitzung zuerst den Befehl HELO und dann MAIL FROM angeben. Wenn MAIL FROM sofort ohne HELO geht, erlauben einige Server eine solche Verbindung (indem sie den Fehlercode 220 zurückgeben), andere nicht (501 oder 503).
Die Standards erfordern auch die Angabe des Domänennamens zusammen mit dem HELO-Befehl. Der Standard erlaubt dies nicht, aber einige Server erlauben es Ihnen, diesen Befehl auszuführen, ohne eine Domäne anzugeben.
Verwenden Sie den Befehl MAIL FROM <Name>, ohne das Zeichen ":* für das Feld FROM anzugeben. Einige Server erlauben dies, obwohl der Standard dies ausdrücklich verbietet.
Verwenden Sie den Befehl MAIL FROM: <> mit einer leeren Absenderadresse. Alle Server müssen dies zulassen, aber es gibt Ausnahmen.
Die Absenderadresse im Befehl MAIL FROM ist falsch eingestellt. Einige Server verbieten dies, dh sie prüfen, ob die angegebene Domäne vorhanden ist.
Eine weitere gängige Methode zur Identifizierung eines SMTP-Servers besteht darin, die Unterstützung einiger Befehle zu überprüfen:
HELP
VRFY
EXPN
TURN
SOML
NOOP
ENLO
Eine weitere interessante Technik ist «Mail-Bouncing". Es ist aufgrund der großen Komplexität und der geringen Arbeitsgeschwindigkeit schwach verbreitet. Der Sinn dieser Technik liegt in der Analyse der Kopfzeilen von E-Mails, die speziell erstellt und an das zu untersuchende Netzwerk gesendet wurden. So sind Briefe für nicht vorhandene Benutzer von Interesse, da sie Benachrichtigungen über die Unmöglichkeit der Zustellung zurückgeben (allerdings nicht immer). Diese Benachrichtigungen enthalten einige Informationen zu den Mailservern, die an der Zustellung der E-Mail beteiligt sind. Anhand mehrerer solcher »Boomerang-E-Mails" können Sie eine bestimmte Anzahl von Knoten im internen Netzwerk (ohne direkten Zugriff darauf) und die Topologie der E-Mail-Weiterleitungen herausfinden. Darüber hinaus ermöglicht das Postprotokoll das Senden von Briefen mit explizitem Hinweis auf mehrere Zwischenübermittlungsstellen. Dies ermöglicht es, eine E-Mail zu erstellen, die nach einer bestimmten Route innerhalb des untersuchten Netzwerks zum Absender zurückkehrt (dies hängt natürlich wesentlich von den Einstellungen der E-Mail-Server ab).
Die so gesammelten Informationen über das Netzwerk sollten einer vergleichenden Analyse mit den Ergebnissen von Social Engineering unterzogen werden, die ich bereits erwähnt habe. Mit den durch Social Engineering erhaltenen Informationen über den verwendeten Mailserver kann ein Netzwerkforscher dies mit den technischen Daten vergleichen. Da die Ergebnisse des Social Engineering genauer und wahrheitsgemäß sind, vergleichen wir sie mit den Informationen über den Mailserver. Wenn die Informationen aus beiden Quellen übereinstimmen, können wir daraus schließen, dass die technischen Mittel der Forschung nicht versuchen, sie zu betrügen, und wir können den Informationen, die sie auf diese Weise erhalten haben, mehr vertrauen.
Webserver.
Ein weiterer wichtiger Dienst auf Anwendungsebene ist NTTR. NTP-Protokoll Version 1.l ist in RFC 2068 beschrieben. Dieses Dokument enthält die OPTIONS-Methode, mit der der NTT-Server die bereitgestellten Informationen über sich selbst zurückgibt.
Zum Beispiel:
OPTIONS "HTTP\I.1.
Tatsächlich habe ich bereits Beispiele solcher Antworten gegeben, als ich die Analyse von «Bannern» beschrieben habe.
Oleg Petukhov, Rechtsanwalt im Bereich des Völkerrechts und des Schutzes personenbezogener Daten, Spezialist für Informationstechnik sicherheit, Schutz von Informationen und persönlichen Daten.
Telegramm-Kanal: https://t.me/datenschutzmit
Die Gruppe im Telegramm: https://t.me/datenschutzmit1
Website: https://legascom.ru
E-Mail: online@legascom.ru
#informationssicherheit #informationssicherheit
Caractéristiques du fonctionnement des protocoles.
Des moyens plus intéressants sont les méthodes basées sur l'analyse des caractéristiques du travail d'un service particulier. L'essence de ces méthodes est d'envoyer des requêtes légèrement différentes de la norme, en utilisant des commandes ou des options rares (peu connues). Pour commencer, considérons l'un des services de réseau les plus courants - le courrier électronique. Maintenant, presque toutes les organisations ont leur propre serveur SMTP, donc l'exemple sera très pertinent.
Serveur SMTP.
Plusieurs normes définissent le comportement du serveur SMTP: RFC 821, RFC 1425, RFC 1985. Ces normes définissent les commandes qu'un client SMTP peut exécuter en se connectant au serveur, les capacités requises du serveur lui-même, les arguments valides et les données. Cependant, comme d'habitude, toutes les implémentations de serveur SMTP ne répondent pas à ces exigences. En outre, les messages d'erreur émis par le serveur SMTP sont également analysés, bien que ces messages puissent être modifiés par l'administrateur du serveur, ce qui réduit la validité de cette méthode. Généralement, un code d'erreur est suffisant. Considérez plusieurs techniques qui vous permettent de distinguer un serveur SMTP d'un autre.
Comme vous le savez, lors de l'installation d'une session SMTP, vous devez d'abord spécifier la commande HELO, puis MAIL FROM. Dans le cas où MAIL FROM va immédiatement, sans HELO, certains serveurs permettent une telle connexion (renvoyant un code d'erreur 220), d'autres l'interdisent (501 ou 503).
Les normes exigent également que le nom de domaine soit spécifié avec la commande HELO. La norme ne permet pas cela, mais certains serveurs vous permettent d'exécuter cette commande sans spécifier de domaine.
Utilisez la commande MAIL FROM <nom > sans spécifier le caractère «:* au champ FROM. Certains serveurs le permettent, bien que la norme l'interdise explicitement.
Utilisez la commande MAIL FROM: < > avec une adresse d'expéditeur vide. Tous les serveurs doivent l'autoriser, mais il y a des exceptions.
L'adresse de l'expéditeur n'est pas définie correctement dans la commande MAIL FROM. Certains serveurs l'interdisent, c'est-à-dire vérifient l'existence du domaine spécifié.
Une autre méthode courante pour identifier un serveur SMTP consiste à vérifier la prise en charge de certaines commandes:
HELP
VRFY
EXPN
TURN
SOML
NOOP
ENLO
Une autre technique intéressante est le «mail-bouncing". Il est faiblement répandu en raison de la complexité et de la faible vitesse de travail. Le but de cette technique est d'analyser les en-têtes des e-mails spécialement composés et envoyés au réseau étudié. Ainsi, les lettres d'intérêt pour les utilisateurs inexistants, car ils renvoient des notifications d'impossibilité de Livraison (bien que pas toujours). Ces notifications contiennent des informations sur les serveurs de messagerie impliqués dans le processus de remise du courrier. Sur la base de plusieurs de ces «lettres-boomerangs», vous pouvez connaître un certain nombre de nœuds du réseau interne (sans accès direct) et la topologie des envois postaux. En outre, le protocole postal vous permet d'envoyer des lettres indiquant explicitement plusieurs points de transfert intermédiaires. Cela permet de créer un e-mail qui, après avoir effectué un itinéraire donné dans le réseau étudié, retournera à l'expéditeur (tout cela, bien sûr, dépend de manière significative des paramètres des serveurs de messagerie).
Les informations ainsi recueillies sur le réseau doivent être comparées aux résultats de l'Ingénierie sociale dont j'ai déjà parlé. En disposant des informations obtenues par l'Ingénierie sociale sur le serveur de messagerie utilisé, l'Explorateur de réseau peut le comparer aux données obtenues par des moyens techniques. Considérant que les résultats de l'Ingénierie sociale sont plus précis et véridiques, nous les comparons aux informations sur le serveur de messagerie. Dans le cas où les informations provenant des deux sources coïncident, nous pouvons conclure que les moyens techniques de recherche ne tentent pas de tromper, et plus de confiance dans les informations obtenues par cette méthode.
Serveur Web.
Un autre service d & apos; application important est le nttr. Protocole nttr version 1.l est décrit dans la RFC 2068. Ce document fournit la méthode OPTIONS, selon laquelle le serveur nttp renvoie des informations détaillées sur lui-même.
Par exemple:
OPTIONS "HTTP\I.1.
En fait, j'ai déjà donné des exemples de telles réponses plus tôt, lorsque j'ai décrit l'analyse des «bannières».
Petukhov Oleg, avocat en droit international et protection des renseignements personnels, spécialiste de l'information sécurité, protection de l'information et des données personnelles.
Canal Telegram: https://t.me/protecciondelainformacion
Groupe au Télégramme: https://t.me/securiteinformatique2
Site: https://legascom.ru
Courriel: online@legascom.ru
#sécuritéinformations #informationsécurité
Caractéristiques du fonctionnement des protocoles.
Des moyens plus intéressants sont les méthodes basées sur l'analyse des caractéristiques du travail d'un service particulier. L'essence de ces méthodes est d'envoyer des requêtes légèrement différentes de la norme, en utilisant des commandes ou des options rares (peu connues). Pour commencer, considérons l'un des services de réseau les plus courants - le courrier électronique. Maintenant, presque toutes les organisations ont leur propre serveur SMTP, donc l'exemple sera très pertinent.
Serveur SMTP.
Plusieurs normes définissent le comportement du serveur SMTP : RFC 821, RFC 1425, RFC 1985. Ces normes définissent les commandes qu'un client SMTP peut exécuter en se connectant au serveur, les capacités requises du serveur lui-même, les arguments valides et les données. Cependant, comme d'habitude, toutes les implémentations de serveur SMTP ne répondent pas à ces exigences. De plus, les messages d'erreur émis par le serveur SMTP sont également analysés, bien que ces messages puissent être modifiés par l'administrateur du serveur, ce qui réduit la validité de cette méthode. Généralement, un code d'erreur est suffisant. Considérez plusieurs techniques qui vous permettent de distinguer un serveur SMTP d'un autre.
Comme vous le savez, lors de l'installation d'une session SMTP, vous devez d'abord spécifier la commande HELO, puis MAIL FROM. Dans le cas où MAIL FROM va immédiatement, sans HELO, certains serveurs permettent une telle connexion (renvoyant un code d'erreur 220), d'autres l'interdisent (501 ou 503).
Les normes exigent également que le nom de domaine soit spécifié avec la commande HELO. La norme ne permet pas cela, mais certains serveurs vous permettent d'exécuter cette commande sans spécifier de domaine.
Utilisez la commande MAIL FROM <nom > sans spécifier le caractère «:* au champ FROM. Certains serveurs le permettent, bien que la norme l'interdise explicitement.
Utilisez la commande MAIL FROM: < > avec une adresse d'expéditeur vide. Tous les serveurs doivent l'autoriser, mais il y a des exceptions.
L'adresse de l'expéditeur n'est pas définie correctement dans la commande MAIL FROM. Certains serveurs l'interdisent, c'est-à-dire vérifient l'existence du domaine spécifié.
Une autre méthode courante pour identifier un serveur SMTP consiste à vérifier la prise en charge de certaines commandes:
HELP
VRFY
EXPN
TURN
SOML
NOOP
ENLO
Une autre technique intéressante est le «mail-bouncing". Il est peu répandu en raison de la complexité et de la faible vitesse de travail. Le but de cette technique est d'analyser les en-têtes des courriels spécialement composés et envoyés au réseau étudié. Ainsi, les lettres d'intérêt pour les utilisateurs inexistants, car ils renvoient des notifications d'impossibilité de livraison (bien que pas toujours). Ces notifications contiennent des informations sur les serveurs de messagerie impliqués dans le processus de remise du courrier. Sur la base de plusieurs de ces « lettres-boomerangs », vous pouvez connaître un certain nombre de nœuds du réseau interne (sans accès direct) et la topologie des envois postaux. Les renseignements ainsi recueillis sur le réseau doivent être comparés aux résultats de l'Ingénierie sociale dont j'ai déjà parlé. En disposant des informations obtenues par l'Ingénierie sociale sur le serveur de messagerie utilisé, l'Explorateur de réseau peut le comparer aux données obtenues par des moyens techniques. Considérant que les résultats de l'ingénierie sociale sont plus précis et véridiques, nous les comparons aux renseignements sur le serveur de messagerie. Dans le cas où les informations provenant des deux sources coïncident, on peut conclure que les moyens techniques de recherche ne tentent pas de tromper, et plus de confiance dans les informations obtenues par cette méthode.
Serveur Web.
Un autre service de table application importante est le nttr. Protocole nttr version 1.l est décrit dans la RFC 2068. Ce document fournit la méthode OPTIONS, selon laquelle le serveur nttp renvoie des informations détaillées sur lui-même.
Par exemple:
OPTIONS « HTTP\I.1.
En fait, j'ai déjà donné des exemples de telles réponses plus tôt, lorsque j'ai décrit l'analyse des «bannières».
Petukhov Oleg, avocat en droit international et protection des renseignements personnels, spécialiste de l'information sécurité, protection de l'information et des données personnelles.
Canal Telegram: https://t.me/protecciondelainformacion
Groupe au Télégramme: https://t.me/securiteinformatique2
Site: https://legascom.ru
Courriel: online@legascom.ru
#sécuritéinformations #informationsécurité
Características de los protocolos.
Los medios más interesantes son los métodos basados en el análisis de las características de un Servicio en particular. La esencia de estos métodos es enviar consultas que son ligeramente diferentes del estándar en el uso de comandos u opciones raros (poco conocidos). Para empezar, considere uno de los servicios de red más comunes: el correo electrónico. Ahora casi cualquier organización tiene su propio servidor SMTP, por lo que un ejemplo sería muy relevante.
Servidor SMTP.
El comportamiento del servidor SMTP está definido por varios estándares: RFC 821, RFC 1425, RFC 1985. Estos estándares definen los comandos que un cliente SMTP puede ejecutar al conectarse al servidor, las capacidades obligatorias del propio servidor, los argumentos válidos y los datos. Sin embargo, como de costumbre, no todas las implementaciones de servidores SMTP cumplen con estos requisitos. Además, los mensajes de error emitidos por el servidor SMTP también se analizan, aunque el administrador del servidor puede modificar estos mensajes, lo que reduce la validez de este método. Por lo general, un código de error es suficiente. Considere algunos trucos para distinguir un servidor SMTP de otro.
Como se sabe, al establecer una sesión SMTP, primero debe especificar el comando HELO, luego MAIL FROM. En caso de que MAIL FROM vaya inmediatamente, sin HELO, algunos servidores permiten dicha conexión (devolviendo el código de error 220), otros lo prohíben (501 o 503).
Además, los estándares requieren especificar un nombre de dominio junto con el comando HELO. El estándar no lo permite, pero algunos servidores le permiten ejecutar este comando sin especificar un dominio.
Usar el comando MAIL FROM < nombre> sin especificar el símbolo ":* para el campo FROM. Algunos servidores lo permiten, aunque el estándar lo prohíbe explícitamente.
Usando el comando MAIL FROM: < > con la dirección del remitente vacía. Todos los servidores deben permitir esto, pero hay excepciones.
Error al especificar la dirección del remitente en el comando MAIL FROM. Algunos servidores lo prohíben, es decir, verifican la existencia del dominio especificado.
Otro método común para identificar un servidor SMTP es verificar la compatibilidad con algunos comandos:
HELP
VRFY
EXPN
TURN
SOML
NOOP
ENLO
Otra técnica interesante es "mail-bouncing". Es poco común debido a la complejidad bastante grande y la baja velocidad de trabajo. El objetivo de esta técnica es analizar los encabezados de los correos electrónicos especialmente redactados y enviados a la red de investigación. Por lo tanto, los correos electrónicos para usuarios inexistentes son de interés, ya que devuelven notificaciones sobre la imposibilidad de entrega (aunque no siempre). Estas notificaciones contienen información sobre los servidores de correo que participan en el proceso de entrega del correo electrónico. Sobre la base de varios de estos "boomerangs", puede conocer un cierto número de nodos de la red interna (sin acceso directo a ella) y la topología de los envíos de correo. Además, el protocolo Postal permite enviar cartas con una indicación explícita de varios puntos de envío intermedios. Esto le permite crear un correo electrónico que, después de haber realizado una ruta determinada dentro de la red investigada, volverá al remitente (todo esto, por supuesto, depende significativamente de la configuración de los servidores de correo).
La información de la red así recopilada debe ser comparada con los resultados de la ingeniería social que mencioné anteriormente. Con la información obtenida a través de la ingeniería social sobre qué servidor de correo se está utilizando, el investigador de la red puede compararlo con los datos obtenidos por medios técnicos. Considerando que los resultados de la ingeniería social son más precisos y veraces, los comparamos con la información del servidor de correo. En el caso de que la información obtenida de ambas Fuentes coincida, podemos concluir que los medios técnicos de investigación no intentan engañar y confiar más en la información obtenida de esta manera.
Servidor web.
Otro Servicio importante a nivel de aplicación es nttr. Protocolo nttr versión 1.l descrito en RFC 2068. En este documento se proporciona el método OPTIONS, según el cual el servidor nttp devuelve la información implementada sobre sí mismo.
Por ejemplo:
OPTIONS "HTTP\I.1.
En realidad, ya he dado ejemplos de tales respuestas antes cuando describí el análisis de"banners".
Oleg Petukhov, abogado en el campo del derecho internacional y la protección de datos personales, especialista en información seguridad, protección de la información y datos personales.
Canal de Telegram: https://t.me/protecciondelainformacion1
Grupo de Telegramas: https://t.me/protecciondelainformacion2
Sitio web: https://legascom.ru
Correo electrónico: online@legascom.ru
#proteccióndelainformación #seguridaddelainformación
Características dos protocolos.
Ferramentas mais interessantes são métodos baseados na análise das características de um determinado serviço. A essência desses métodos é enviar consultas que são um pouco diferentes do padrão, usando comandos ou opções raras (pouco conhecidas). Para começar, vamos considerar um dos serviços de rede mais comuns - e-mail. Agora, quase todas as organizações têm o seu próprio servidor SMTP, por isso o exemplo será muito relevante.
Servidor SMTP.
O comportamento de um servidor SMTP é definido por vários padrões: RFC 821, RFC 1425, RFC 1985. Esses padrões definem os comandos que um cliente SMTP pode executar ao se conectar a um servidor, as capacidades obrigatórias do próprio servidor, argumentos e dados válidos. No entanto, como de costume, nem todas as implementações de servidores SMTP atendem a esses requisitos. Além disso, as mensagens de erro emitidas pelo servidor SMTP também devem ser analisadas, embora essas mensagens possam ser alteradas pelo administrador do servidor, o que reduz a validade desse método. Geralmente, um código de erro é suficiente. Considere algumas técnicas para distinguir um servidor SMTP de outro.
Como você sabe, ao estabelecer uma sessão SMTP, você deve primeiro especificar o comando HELO, depois MAIL FROM. Se o MAIL FROM for imediatamente, sem HELO, alguns servidores permitem essa conexão (retornando o código de erro 220), outros proíbem (501 ou 503).
Além disso, os padrões exigem que o nome de domínio seja especificado juntamente com o comando HELO. O padrão não permite isso, mas alguns servidores permitem que você execute esse comando sem especificar um domínio.
Use o comando MAIL FROM < nome>sem especificar o caractere": * para o campo FROM. Alguns servidores permitem isso, embora o padrão proíba explicitamente.
Use o comando MAIL FROM: < > com um endereço de E-mail vazio. Todos os servidores devem permitir isso, mas há exceções.
A configuração do endereço do remetente no comando MAIL FROM é inválida. Alguns servidores proíbem isso, ou seja, verificam a existência do domínio especificado.
Outro método comum para identificar um servidor SMTP é verificar o suporte para alguns comandos:
HELP
VRFY
EXPN
TURN
SOML
NOOP
OOKLO
Outra técnica interessante é o "mail-bouncing". É pouco comum devido à complexidade bastante grande e à baixa velocidade do trabalho. O Significado desta técnica é analisar os cabeçalhos dos E-mails especialmente compilados e enviados para a rede em estudo. Assim, de interesse são e-mails para usuários inexistentes, porque eles retornam notificações sobre a impossibilidade de entrega (no entanto, nem sempre). Essas notificações contêm algumas informações sobre os servidores de E-mail envolvidos no processo de entrega do E-mail. Com base em algumas dessas "cartas bumerangues", pode-se reconhecer um número de nós na rede interna (sem acesso direto a ela) e a topologia de encaminhamentos de correio. Além disso, o protocolo de E-mail permite o envio de E-mails com a indicação explícita de vários pontos de encaminhamento intermediários. Isso torna possível criar um e-mail que, depois de fazer uma rota especificada dentro da rede em estudo, retornará ao remetente (tudo isso, é claro, depende significativamente das configurações dos servidores de E-mail).
As informações coletadas sobre a rede devem ser comparadas com os resultados da engenharia social que mencionei anteriormente. Com os dados da engenharia social sobre qual servidor de E-mail está sendo usado, um pesquisador de rede pode compará-lo com os dados obtidos por meios técnicos. Considerando que os resultados da engenharia social são mais precisos e verdadeiros, nós os comparamos com as informações do servidor de E-mail. Se as informações obtidas de ambas as fontes coincidirem, podemos concluir que os meios técnicos de pesquisa não estão tentando enganar e confiar mais nas informações obtidas dessa maneira.
Servidor web.
Outro serviço importante da camada de aplicação é o NTTR. Protocolo NTTR versão 1.descrito na RFC 2068. Este documento fornece o método OPTIONS, segundo o qual o servidor NTT retorna informações detalhadas sobre si mesmo.
Por exemplo:
OPTIONS "HTTP\I.1.
Na verdade, já dei exemplos de tais respostas antes, quando descrevi a análise de "banners".
Petukhov Oleg, advogado de Direito Internacional e proteção de dados pessoais, especialista em informação segurança, proteção de informações e dados pessoais.
Canal do Telegram: https://t.me/protecaodaInformacao
Grupo em Telegram: https://t.me/protecaodaInformacao1
Site: https://legascom.ru
Correio eletrónico: online@legascom.ru
#segurançadaInformação #Segurançadainformação
Recursos de operação do protocolo.
Ferramentas mais interessantes são métodos baseados em uma análise das especificidades de um determinado serviço. A essência desses métodos é enviar solicitações ligeiramente diferentes do padrão e usar comandos ou opções raros (pouco conhecidos). Primeiro, vejamos um dos serviços online mais comuns - e-mail. Agora, quase todas as organizações têm seu próprio servidor SMTP, então o exemplo será muito relevante.
Servidor SMTP.
O comportamento do servidor SMTP é definido por vários padrões: RFC 821, RFC 1425, RFC 1985. Esses padrões definem os comandos que o cliente SMTP pode executar conectando-se ao servidor, os recursos necessários do próprio servidor e argumentos e dados aceitáveis. No entanto, como de costume, nem todas as implementações de servidor SMTP atendem a esses requisitos. Além disso, as mensagens de erro do servidor SMTP estão sujeitas a análise, embora essas mensagens possam ser alteradas pelo administrador do servidor, o que reduz a confiabilidade desse método. Como regra, um código de erro é suficiente. Vejamos várias técnicas para distinguir um servidor SMTP de outro.
Como você sabe, ao estabelecer uma sessão SMTP, você deve primeiro especificar o comando HELO e, em seguida, MAIL FROM. Se o MAIL FROM for imediatamente, sem HELO, alguns servidores permitem essa conexão (retornando o código de erro 220), outros a proíbem (501 ou 503).
Os padrões também exigem a especificação do nome de domínio junto com o comando HELO. O padrão não permite isso, mas alguns servidores permitem que você execute este comando sem especificar o domínio.
Usando o comando MAIL FROM <name> sem especificar o campo ":* The FROM. Alguns servidores permitem isso, embora a norma proíba explicitamente.
Usando o comando MAIL FROM: < > com o endereço do remetente vazio. Todos os servidores devem permitir isso, mas há exceções.
Configuração incorreta do endereço do remetente no comando MAIL FROM. Alguns servidores proíbem isso, ou seja, verificam a existência do domínio especificado.
Um outro método comum da identificação do servidor SMTP é verificar o apoio de determinados comandos:
Ajuda
VRFY
EXPN
TURN
SOML
NOOP
ENLO
Outra técnica interessante é o "mail-bouncing". É mal distribuído devido à sua complexidade bastante alta e baixa velocidade de operação. O objetivo desta técnica é analisar os cabeçalhos de E-mails especialmente compilados e enviados para a rede em estudo. Assim, as cartas para usuários inexistentes são de interesse, pois retornam notificações sobre a impossibilidade de entrega (embora nem sempre). Essas notificações contêm algumas informações sobre os servidores de E-mail envolvidos no processo de entrega de E-mail. Com base em várias dessas "letras do Bumerangue", você pode descobrir um certo número de nós na rede interna (sem ter acesso direto a ela) e a topologia das remessas de correio. Além disso, o protocolo mail Permite enviar e-mails com indicação explícita de vários pontos intermediários de encaminhamento. Isso possibilita a criação de um e-mail que, após concluir uma rota definida dentro da rede em estudo, retornará ao remetente (tudo isso, é claro, depende significativamente das configurações dos servidores de E-mail).
As informações assim coletadas sobre a rede devem ser submetidas a uma análise comparativa com os resultados da engenharia social, que mencionei anteriormente. Com as informações obtidas por meio da engenharia social sobre qual servidor de E-mail está sendo utilizado, o pesquisador da rede pode comparar isso com os dados que foram obtidos por meios técnicos. Considerando que os resultados da engenharia social são mais precisos e verdadeiros, nós os comparamos com informações sobre o servidor de E-mail. Se as informações obtidas das duas fontes forem as mesmas, podemos concluir que os meios técnicos de pesquisa não estão tentando enganar, e podemos confiar mais nas informações obtidas dessa forma.
O servidor web.
Outro serviço importante da camada de aplicação é o NTTP. O protocolo HTTP versão 1.l é descrito na RFC 2068. Este documento fornece o método OPTIONS, de acordo com o qual o Servidor HTTP retorna informações detalhadas sobre si mesmo.
Por exemplo:
Opções " HTTP\I. 1.
Na verdade, já dei exemplos dessas respostas anteriormente, quando descrevi a análise de "banners".
Petukhov Oleg, advogado de Direito Internacional e proteção de dados pessoais, especialista em informação segurança, proteção de informações e dados pessoais.
Canal do Telegram: https://t.me/protecaodaInformacao
Grupo em Telegram: https://t.me/protecaodaInformacao1
Site: https://legascom.ru
Correio eletrónico: online@legascom.ru
#segurançadaInformação #Segurançadainformação
Caratteristiche dei protocolli.
Mezzi più interessanti sono metodi basati sull'analisi delle caratteristiche del lavoro di un particolare servizio. L'essenza di questi metodi è inviare query leggermente diverse dallo standard nell'uso di comandi o opzioni rari (poco conosciuti). Per cominciare, considera uno dei servizi di rete più comuni: la posta elettronica. Ora quasi tutte le organizzazioni hanno il proprio server SMTP, quindi l'esempio sarà molto rilevante.
Server SMTP.
Diversi standard definiscono il comportamento del server SMTP: RFC 821, RFC 1425, RFC 1985. Questi standard specificano i comandi che un client SMTP può eseguire quando si connette a un server, le capacità richieste del server stesso, gli argomenti e i dati validi. Tuttavia, come al solito, non tutte le implementazioni di server SMTP soddisfano questi requisiti. Inoltre, i messaggi di errore generati dal server SMTP sono soggetti all'analisi, sebbene questi messaggi possano essere modificati dall'amministratore del server, il che riduce la validità di questo metodo. In genere è sufficiente un codice di errore. Considera diversi trucchi per distinguere un server SMTP da un altro.
Come sapete, quando si stabilisce una sessione SMTP, è necessario specificare prima il comando HELO, quindi MAIL FROM. Nel caso in cui MAIL FROM vada subito, senza HELO, alcuni server consentono tale connessione (restituendo un codice di errore 220), altri vietano (501 o 503).
Inoltre, gli standard richiedono di specificare un nome di dominio insieme al comando HELO. Lo standard non lo consente, ma alcuni server consentono di eseguire questo comando senza specificare un dominio.
Utilizzare il comando MAIL FROM < nome> senza specificare il carattere «:* nel campo FROM. Alcuni server lo consentono, sebbene lo standard lo proibisca esplicitamente.
Utilizzo del comando MAIL FROM: < > con l'indirizzo del mittente vuoto. Tutti i server devono consentire questo, ma ci sono eccezioni.
Impostazione errata dell'indirizzo del mittente nel comando MAIL FROM. Alcuni server lo vietano, ovvero controllano l'esistenza di detto dominio.
Un altro metodo comune per identificare un server SMTP è verificare il supporto per alcuni comandi:
HELP
VRFY
EXPN
TURN
SOML
NOOP
Enlo
Un'altra tecnica interessante è "mail-bouncing". È debolmente diffuso a causa della complessità piuttosto elevata e della bassa velocità di lavoro. Il punto di questa tecnica è analizzare le intestazioni delle e-mail appositamente composte e inviate alla rete in esame. Pertanto, le e-mail per utenti inesistenti sono di interesse, poiché restituiscono notifiche sull'impossibilità di consegna (anche se non sempre). Queste notifiche contengono alcune informazioni sui server di posta coinvolti nel processo di consegna della lettera. Sulla base di diverse di queste «lettere Boomerang», è possibile scoprire un certo numero di nodi della rete interna (senza accesso diretto ad essa) e la topologia degli Invii di posta. Inoltre, il protocollo di posta consente di inviare e-mail con l'indicazione esplicita di più punti di inoltro intermedi. Ciò consente di creare un'e-mail che, dopo aver percorso un determinato percorso all'interno della rete studiata, tornerà al mittente (tutto ciò, ovviamente, dipende in modo significativo dalle impostazioni dei server di posta).
Le informazioni di rete raccolte in questo modo devono essere confrontate con i risultati dell'ingegneria sociale che ho menzionato prima. Con le informazioni ottenute attraverso l'ingegneria sociale su quale server di posta viene utilizzato, il ricercatore di rete può confrontarlo con i dati ottenuti con mezzi tecnici. Considerando che i risultati dell'ingegneria sociale sono più accurati e veritieri, li confrontiamo con le informazioni sul server di posta. Nel caso in cui le informazioni ottenute da entrambe le fonti coincidano, possiamo concludere che i mezzi tecnici di ricerca non stanno cercando di ingannare e fidarsi maggiormente delle informazioni ottenute in questo modo.
Server Web.
Un altro importante servizio a livello di applicazione è HTTP. Protocollo HTTP versione 1.l è descritto in RFC 2068. Questo documento fornisce il metodo OPTIONS, in base al quale il server HTTP restituisce informazioni dettagliate su se stesso.
Ad esempio:
OPTIONS "HTTP\I.1.
In realtà, ho già dato esempi di tali risposte in precedenza quando ho descritto l'analisi dei «banner».
Oleg Petukhov, avvocato nel campo del diritto internazionale e della protezione dei dati personali, specialista nel campo dell'informazione sicurezza, protezione delle informazioni e dei dati personali.
Canale Telegram: https://t.me/protezionedelleinformazioni
Gruppo in telegramma: https://t.me/protezionedelleinformazioni1
Sito: https://legascom.ru
E-mail: online@legascom.ru
#protezionedelleInformazioni #sicurezzadelleinformazioni
