Безопасность DNS.
Безопасность DNS.
Для предотвращения атак на отравление кеша DNS необходимо выполнить ряд действий, описанных в этом разделе. Многие атаки на кеш могут быть предотвращены на стороне DNS-серверов с помощью уменьшения степени доверия к информации, приходящей от других DNS-серверов, или даже игнорирования любых DNS-записей, не относящихся прямо к запросам. Так, к примеру, последние версии сервера DNS BIND выполняют такие проверки. Кроме того, использование случайных UDP-портов для выполнения DNS-запросов может существенно снизить вероятность успешной атаки на кеш. Однако не стоит забывать, что различное межсетевое оборудование (маршрутизаторы, файрволлы), через которые проходят запросы к DNS-серверам, выполняющее трансляцию адресов (NAT) или, более конкретно, трансляцию портов (PAT), часто подменяет порт, используемый для выполнения запросов, для отслеживания соединения. При этом устройства, выполняющие PAT, обычно используют свои алгоритмы нумерации исходящих портов, тем самым теряя случайность при выборе порта, созданную DNS-сервером.
Более мощным средством защиты является безопасный DNS (DNSSEC), использующий электронно-цифровую подпись с построением цепочки доверия для определения целостности данных. Применение DNSSEC может свести результативность атак на кеш к нулю, и к 2011 году внедрение DNSSEC идет уже быстрыми темпами (большинство доменных зон gTLD, таких как .com, .net, .org, уже подписаны DNSSEC). Начиная с июля 2010 года корневые серверы DNS содержат корневую зону DNS, подписанную при помощи стандартов DNSSEC.
Атакам на кеш также можно противопоставить транспортный уровень либо уровень приложений модели OSI, т. к. на этих уровнях могут быть использованы цифровые подписи. К примеру, в безопасной версии HTTP - HTTPS - пользователь может проверить, имеет ли сервер, с которым он соединился, сертификат ЭЦП и кому этот сертификат принадлежит. Похожий уровень безопасности имеет SSH, когда программа-клиент проверяет ЭЦП удаленного сервера при инициации соединения. Соединение с помощью IPSEC не установится, если клиентом и сервером не будут предъявлены заранее известные ключи ЭЦП. Приложения, которые загружают свои обновления автоматически, могут иметь встроенную копию сертификата ЭЦП и проверять подлинность обновлений с помощью сравнения ЭЦП сервера обновлений с встроенным сертификатом.
Петухов Олег, юрист в области международного права и защиты персональных данных, специалист в области информационной безопасности, защиты информации и персональных данных.
Телеграм-канал: https://t.me/zashchitainformacii
Группа в Телеграм: https://t.me/zashchitainformacii1
Сайт: https://legascom.ru
Электронная почта: online@legascom.ru
#защитаинформации #информационнаябезопасность
DNS security.
To prevent DNS cache poisoning attacks, follow the steps described in this section. Many cache attacks can be prevented on the DNS server side by reducing the degree of trust in information coming from other DNS servers, or even ignoring any DNS records that are not directly related to queries. For example, the latest versions of the BIND DNS server perform such checks. In addition, using random UDP ports to perform DNS queries can significantly reduce the likelihood of a successful cache attack. However, do not forget that various inter-network equipment (routers, firewalls) through which requests to DNS servers pass, performing address translation (NAT) or, more specifically, port translation (PAT), often replaces the port used to make requests to track the connection. At the same time, PAT devices usually use their own algorithms for numbering outgoing ports, thereby losing the port selection randomness created by the DNS server.
A more powerful means of protection is secure DNS (DNSSEC), which uses an electronic digital signature with a chain of trust to determine data integrity. The use of DNSSEC can reduce the effectiveness of cache attacks to zero, and by 2011, the implementation of DNSSEC was already proceeding rapidly (most gTLD domain zones, such as .com, .net, and .org, were already signed by DNSSEC). Since July 2010, DNS root servers contain a DNS root zone signed using DNSSEC standards.
Cache attacks can also be countered by the transport layer or the application layer of the OSI model, since digital signatures can be used at these levels. For example, in the secure version of HTTP - HTTPS - the user can check whether the server he is connected to has an EDS certificate and to whom this certificate belongs. SSH has a similar level of security when the client program checks the remote server's EDS when initiating a connection. An IPSEC connection will not be established unless the client and server are provided with pre-known EDS keys. Applications that download their updates automatically may have an embedded copy of the EDS certificate and verify the authenticity of updates by comparing the update server's EDS with the embedded certificate.
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
DNS-Sicherheit.
Um Angriffe auf DNS-Cache-Vergiftungen zu verhindern, müssen Sie eine Reihe von Schritten in diesem Abschnitt ausführen. Viele Cache-Angriffe können auf der Seite von DNS-Servern verhindert werden, indem das Vertrauen in Informationen von anderen DNS-Servern verringert oder sogar alle DNS-Einträge ignoriert werden, die nicht direkt auf Abfragen zutreffen. So führen beispielsweise die neuesten Versionen des DNS-BIND-Servers solche Überprüfungen durch. Darüber hinaus kann die Verwendung zufälliger UDP-Ports zum Ausführen von DNS-Abfragen die Wahrscheinlichkeit eines erfolgreichen Cache-Angriffs erheblich reduzieren. Vergessen Sie jedoch nicht, dass verschiedene Firewall-Geräte (Router, Firewalls), die Anfragen an DNS-Server senden, die Adressübertragungen (NAT) oder genauer gesagt Portübertragungen (PAT) durchführen, häufig den Port ersetzen, der zum Ausführen von Abfragen verwendet wird, um die Verbindung zu verfolgen. Die Geräte, die PAT ausführen, verwenden normalerweise ihre Algorithmen zur Nummerierung ausgehender Ports, wodurch die vom DNS-Server erstellte Portauswahl an Zufälligkeit verliert.
Ein stärkerer Schutz ist das sichere DNS (DNSSEC), das eine elektronisch-digitale Signatur mit einer Vertrauenskette verwendet, um die Integrität der Daten zu ermitteln. Die Anwendung von DNSSEC kann die Effektivität von Cache-Angriffen auf Null reduzieren, und die Implementierung von DNSSEC ist bereits im Gange (die meisten gTLD-Domänen, wie .com, .net, .org, sind bereits von DNSSEC signiert), bis 2011 ist die Implementierung von DNSSEC bereits in einem rasanten Tempo vorangekommen (die meisten gTLD-Domänen, z. B. .com, .net, .org, sind bereits von DNSSEC signiert). Seit Juli 2010 enthalten DNS-Stammserver eine mit DNSSEC-Standards signierte DNS-Stammzone.
Cache-Angriffe können auch der Transportschicht oder der Anwendungsschicht des OSI-Modells entgegengesetzt werden, da digitale Signaturen auf diesen Ebenen verwendet werden können. Beispielsweise kann ein Benutzer in einer sicheren Version von HTTP - HTTPS überprüfen, ob der Server, mit dem er eine Verbindung hergestellt hat, über ein EDC-Zertifikat verfügt und wem dieses Zertifikat gehört. Eine ähnliche Sicherheitsstufe hat SSH, wenn das Clientprogramm die EDC des Remoteservers überprüft, wenn eine Verbindung hergestellt wird. Eine IPSEC-Verbindung wird nicht hergestellt, es sei denn, der Client und der Server haben bereits bekannte EDC-Schlüssel vorgelegt. Anwendungen, die ihre Updates automatisch herunterladen, können über eine eingebettete Kopie des EDC-Zertifikats verfügen und die Aktualisierung authentifizieren, indem sie den EDC des Update-Servers mit dem eingebetteten Zertifikat vergleichen.
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
Sécurité DNS.
Pour éviter les attaques d'empoisonnement du cache DNS, vous devez suivre les étapes décrites dans cette section. De nombreuses attaques de cache peuvent être évitées du côté des serveurs DNS en réduisant la confiance dans les informations provenant d'autres serveurs DNS ou même en ignorant les enregistrements DNS qui ne sont pas directement liés aux requêtes. Par exemple, les dernières versions du serveur DNS BIND effectuent de telles vérifications. En outre, l'utilisation de ports UDP aléatoires pour effectuer des requêtes DNS peut réduire considérablement la probabilité d'une attaque réussie sur le cache. Cependant, il ne faut pas oublier que les différents pare-feu (routeurs, pare-feu) à travers lesquels passent les requêtes aux serveurs DNS, qui effectuent la traduction d'adresse (NAT) ou, plus précisément, la traduction de port (PAT), remplacent souvent le port utilisé pour effectuer les requêtes pour suivre la connexion. Dans ce cas, les périphériques exécutant PAT utilisent généralement leurs algorithmes de numérotation des ports sortants, perdant ainsi le caractère aléatoire généré par le serveur DNS lors de la sélection du port.
Une protection plus puissante est le DNS sécurisé (DNSSEC), qui utilise une signature numérique avec une chaîne de confiance pour déterminer l'intégrité des données. L'utilisation de DNSSEC peut réduire l'impact des attaques de cache à zéro, et d'ici 2011, l'adoption de DNSSEC est déjà rapide (la plupart des domaines gTLD tels que .com, .net,. org sont déjà signés par DNSSEC). Depuis juillet 2010, les serveurs DNS racine contiennent une zone DNS racine signée à l'aide des normes DNSSEC.
Les attaques de cache peuvent également être opposées à la couche de transport ou à la couche d'application du modèle OSI, car ces couches peuvent utiliser des signatures numériques. Par exemple, dans une version sécurisée HTTP - HTTPS, un utilisateur peut vérifier si le serveur auquel il s'est connecté possède un certificat EDS et à qui appartient ce certificat. Un niveau de sécurité similaire a SSH lorsque le programme client vérifie l'EDS du serveur distant lors de l'initiation de la connexion. La connexion IPSEC ne sera pas établie si le client et le serveur ne présentent pas les clés EEC connues à l'avance. Les applications qui téléchargent automatiquement leurs mises à jour peuvent avoir une copie intégrée du certificat EDS et authentifier les mises à jour en comparant l'EDS du serveur de mise à jour avec le certificat intégré.
Petukhov Oleg, avocat en droit international et protection des données personnelles, spécialiste de l'information sécurité, protection de l'information et des données personnelles.
Telegram Channel: https://t.me/protecciondelainformacion
Groupe au Télégramme: https://t.me/securiteinformatique2
Site: https://legascom.ru
E-mail: online@legascom.ru
#sécuritéinformations #informationsécurité
Sécurité DNS.
Pour éviter les attaques d'empoisonnement du cache DNS, vous devez suivre les étapes décrites dans cette section. De nombreuses attaques de cache peuvent être évitées du côté des serveurs DNS en réduisant la confiance dans les informations provenant d'autres serveurs DNS ou même en ignorant les enregistrements DNS qui ne sont pas directement liés aux requêtes. Par exemple, les dernières versions du serveur DNS BIND effectuent de telles vérifications. De plus, l'utilisation de ports UDP aléatoires pour effectuer des requêtes DNS peut réduire considérablement la probabilité d'une attaque réussie sur le cache. Cependant, il ne faut pas oublier que les différents pare-feu (routeurs, pare-feu) à travers lesquels passent les requêtes aux serveurs DNS, qui effectuent la traduction d'adresse (NAT) ou, plus précisément, la traduction de port (PAT), remplacent souvent le port utilisé pour effectuer les requêtes pour suivre la connexion. Dans ce cas, les périphériques exécutant PAT utilisent généralement leurs algorithmes de numérotation des ports sortants, perdant ainsi le caractère aléatoire généré par le serveur DNS lors de la sélection du port.
Une protection plus puissante est le DNS sécurisé (DNSSEC), qui utilise une signature numérique avec une chaîne de confiance pour déterminer l'intégrité des données. L'utilisation de DNSSEC peut réduire l'impact des attaques de cache à zéro, et d'ici 2011, l'adoption de DNSSEC est déjà rapide (la plupart des domaines gTLD tels que .com, .net,. org sont déjà signés par DNSSEC). Depuis juillet 2010, les serveurs DNS racine contiennent une zone DNS racine signée à l'aide des normes DNSSEC.
Les attaques de cache peuvent également être opposées à la couche de transport ou à la couche d'application du modèle OSI, car ces couches peuvent utiliser des signatures numériques. Par exemple, dans une version sécurisée HTTP - HTTPS, un utilisateur peut vérifier si le serveur auquel il s'est connecté possède un certificat EDS et à qui appartient ce certificat. Un niveau de sécurité similaire a SSH lorsque le programme client vérifie l'EDS du serveur distant lors de l'initiation de la connexion. La connexion IPSEC ne sera pas établie si le client et le serveur ne présentent pas les clés EEC connues à l'avance. Les applications qui téléchargent automatiquement leurs mises à jour peuvent avoir une copie intégrée du certificat EDS et authentifier les mises à jour en comparant l'EDS du serveur de mise à jour avec le certificat intégré.
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é
Seguridad DNS.
Para evitar ataques de envenenamiento de caché de DNS, debe realizar una serie de acciones que se describen en esta sección. Muchos ataques de caché se pueden prevenir en el lado de los servidores DNS reduciendo la confianza en la información proveniente de otros servidores DNS, o incluso ignorando cualquier registro DNS que no esté directamente relacionado con las consultas. Por ejemplo, las versiones más recientes del servidor DNS BIND realizan estas comprobaciones. Además, el uso de puertos UDP aleatorios para realizar consultas DNS puede reducir sustancialmente la probabilidad de un ataque exitoso a la memoria caché. Sin embargo, tenga en cuenta que los diversos equipos de interconexión (routers, firewalls) a través de los cuales pasan las solicitudes a los servidores DNS, que realizan la traducción de direcciones (NAT) o, más específicamente, la traducción de puertos (PAT), a menudo sustituyen el puerto utilizado para realizar las solicitudes para rastrear la conexión. Al hacerlo, los dispositivos que ejecutan PAT generalmente usan sus algoritmos de numeración de puertos salientes, perdiendo así la aleatoriedad en la selección de puertos creada por el servidor DNS.
Una protección más poderosa es el DNS seguro (DNSSEC), que utiliza una firma digital con la construcción de una cadena de confianza para determinar la integridad de los datos. El uso de DNSSEC puede reducir la efectividad de los ataques a la memoria caché a cero, y para 2011, la implementación de DNSSEC ya está en marcha (la mayoría de los dominios gTLD, como .com, .Net,. org, ya están firmados por DNSSEC). A partir de julio de 2010, los servidores DNS raíz contienen una zona raíz DNS firmada con los estándares DNSSEC.
Los ataques de caché también se pueden contrarrestar con la capa de transporte o la capa de aplicación del modelo OSI, ya que las firmas digitales se pueden usar en estos niveles. Por ejemplo, en la versión segura de HTTP - HTTPS, el usuario puede verificar si el servidor al que se ha conectado tiene un certificado EDS y a quién pertenece ese certificado. Un nivel de seguridad similar tiene SSH cuando el programa cliente verifica el EDS del servidor remoto cuando se inicia la conexión. La conexión IPSEC no se establecerá a menos que el cliente y el servidor presenten claves EDS conocidas previamente. Las aplicaciones que descargan sus actualizaciones automáticamente pueden tener una copia integrada del certificado EDS y autenticar las actualizaciones comparando el EDS del servidor de actualizaciones con el certificado integrado.
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
Segurança do DNS.
Para evitar ataques de envenenamento de cache DNS, você precisa seguir uma série de etapas descritas nesta seção. Muitos ataques de cache podem ser evitados no lado dos servidores DNS, reduzindo a confiança em informações provenientes de outros servidores DNS, ou mesmo ignorando quaisquer registros DNS que não sejam diretamente relacionados às consultas. Por exemplo, as versões mais recentes do DNS BIND executam essas verificações. Além disso, o uso de portas UDP aleatórias para executar consultas DNS pode reduzir significativamente a probabilidade de um ataque de cache bem-sucedido. No entanto, deve-se ter em mente que os vários equipamentos de firewall (roteadores, firewalls) através dos quais as solicitações para servidores DNS realizam tradução de endereços (NAT) ou, mais especificamente, tradução de portas (PAT), muitas vezes substituem a porta usada para realizar as solicitações para rastrear a conexão. Os dispositivos que executam o PAT geralmente usam seus algoritmos de numeração de porta de saída, perdendo assim a aleatoriedade de selecionar uma porta criada pelo servidor DNS.
Uma proteção mais poderosa é o DNS seguro (DNSSEC), que usa uma assinatura eletrônica e digital para criar uma cadeia de confiança para determinar a integridade dos dados. O uso do DNSSEC pode reduzir a eficácia dos ataques de cache a zero e, em 2011, a implementação do DNSSEC já está em um ritmo acelerado (a maioria dos gTLDs, como .com, .net,. org, já são assinados pelo DNSSEC). A partir de julho de 2010, os servidores raiz do DNS contêm uma zona raiz do DNS assinada usando os padrões DNSSEC.
Os ataques de cache também podem ser contrastados com a camada de transporte ou a camada de aplicativo do modelo OSI, pois as assinaturas digitais podem ser usadas nessas camadas. Por exemplo, em uma versão segura do HTTP, HTTPS, o usuário pode verificar se o servidor ao qual ele se conectou possui um certificado EDC e a quem esse certificado pertence. Um nível de segurança semelhante é fornecido pelo SSH quando o programa cliente verifica o EDS do servidor remoto quando a conexão é iniciada. A ligação IPSEC não será estabelecida a menos que o cliente e o servidor apresentem chaves de EDC previamente conhecidas. Os aplicativos que baixam suas atualizações automaticamente podem ter uma cópia incorporada do certificado EDC e autenticar as atualizações comparando o EDC do servidor de atualização com o certificado incorporado.
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
Segurança DNS.
Para evitar ataques de envenenamento de cache DNS, siga as etapas descritas nesta seção. Muitos ataques de cache podem ser evitados no lado do servidor DNS, reduzindo o grau de confiança nas informações provenientes de outros servidores DNS, ou mesmo ignorando quaisquer registros DNS que não estejam diretamente relacionados às consultas. Por exemplo, as versões mais recentes do servidor DNS BIND executam essas verificações. Além disso, o uso de portas UDP aleatórias para executar consultas DNS pode reduzir significativamente a probabilidade de um ataque de cache bem-sucedido. No entanto, não se esqueça que vários equipamentos inter-rede (roteadores, firewalls) pelos quais passam as solicitações aos servidores DNS, realizando a tradução de endereços (NAT) ou, mais especificamente, a tradução de portas (PAT), muitas vezes substituem a porta usada para fazer solicitações para rastrear a conexão. Ao mesmo tempo, os dispositivos PAT geralmente usam seus próprios algoritmos para numerar portas de saída, perdendo assim a aleatoriedade de seleção de porta criada pelo servidor DNS.
Um meio de proteção mais poderoso é o DNS seguro (DNSSEC), que usa uma assinatura digital eletrônica com uma cadeia de confiança para determinar a integridade dos dados. O uso do DNSSEC pode reduzir a eficácia dos ataques de cache a zero e, em 2011, a implementação do DNSSEC já estava ocorrendo rapidamente (a maioria das zonas de domínio gTLD, como .com,. NET e.org, já estavam assinadas pelo DNSSEC). Desde julho de 2010, os servidores raiz DNS contêm uma zona raiz DNS assinada usando os padrões DNSSEC.
Os ataques de Cache também podem ser combatidos pela camada de transporte ou pela camada de aplicação do modelo OSI, uma vez que as assinaturas digitais podem ser usadas nesses níveis. Por exemplo, na versão segura do HTTP - HTTPS - o usuário pode verificar se o servidor ao qual está conectado possui um certificado EDS e a quem esse certificado pertence. O SSH tem um nível de segurança semelhante quando o programa cliente verifica o EDS do servidor remoto ao iniciar uma conexão. Uma conexão IPSEC não será estabelecida a menos que o cliente e o servidor sejam fornecidos com chaves EDS pré-conhecidas. Os aplicativos que baixam suas atualizações automaticamente podem ter uma cópia incorporada do certificado EDS e verificar a autenticidade das atualizações comparando o EDS do servidor de atualização com o certificado incorporado.
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
Sicurezza DNS.
Per prevenire gli attacchi di avvelenamento della cache DNS, è necessario eseguire una serie di passaggi descritti in questa sezione. Molti attacchi alla cache possono essere prevenuti sul lato server DNS riducendo il grado di fiducia nelle informazioni provenienti da altri server DNS o addirittura ignorando eventuali record DNS non direttamente rilevanti per le query. Quindi, ad esempio, le ultime versioni del server DNS BIND eseguono tali controlli. Inoltre, l'utilizzo di porte UDP casuali per eseguire query DNS può ridurre sostanzialmente le possibilità di un attacco riuscito alla cache. Tuttavia, non dimenticare che le varie apparecchiature di interconnessione (router, firewall) attraverso le quali passano le query ai server DNS che eseguono la traduzione degli indirizzi (NAT) o, più specificamente, la traduzione delle porte (PAT) spesso sostituiscono la porta utilizzata per eseguire le query per tracciare la connessione. In tal modo, i dispositivi che eseguono PAT di solito utilizzano i loro algoritmi di numerazione delle porte in uscita, perdendo così la casualità nella selezione delle porte creata dal server DNS.
Una protezione più potente è il DNS sicuro (DNSSEC), che utilizza una firma digitale elettronica con la costruzione di una catena di fiducia per determinare l'integrità dei dati. L'applicazione di DNSSEC può ridurre a zero l'efficacia degli attacchi alla cache e, entro il 2011, L'implementazione di DNSSEC è già a un ritmo rapido (la maggior parte delle zone di dominio gTLD come .com,. NET,. org sono già firmate da DNSSEC). A partire da luglio 2010, i server radice DNS contengono una zona radice DNS firmata con gli standard DNSSEC.
Gli attacchi alla cache possono anche essere contrastati dal livello di trasporto o dal livello di applicazione del modello OSI, poiché a questi livelli possono essere utilizzate firme digitali. Ad esempio, in una versione sicura, un utente HTTP - HTTPS può verificare se il server a cui si è connesso dispone di un certificato EDS e a chi appartiene il certificato. SSH ha un livello di sicurezza simile quando il programma client verifica L'EDS del server remoto quando viene avviata una connessione. La connessione tramite IPSEC non verrà stabilita a meno che il client e il server non presentino chiavi EDS note in anticipo. Le applicazioni che scaricano automaticamente gli aggiornamenti possono avere una copia incorporata del certificato EDS e verificare l'autenticità degli aggiornamenti confrontando L'EDS del server di aggiornamento con il certificato incorporato.
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
