Conhecendo o MQTT

Por que o MQTT é um dos melhores protocolos de rede para a Internet das Coisas?

Para os dispositivos de Internet das Coisas (IoT), a conexão com a Internet é um requisito. A conexão com a Internet permite que os dispositivos trabalhem entre si e com serviços de backend. O protocolo de rede subjacente da Internet é o TCP/IP. Desenvolvido com base na pilha TCP/IP, o MQTT (Message Queue Telemetry Transport) tornou-se o padrão para comunicações de IoT.

O MQTT foi inventado e desenvolvido inicialmente pela IBM no final dos anos 90. Sua aplicação original era vincular sensores em pipelines de petróleo a satélites. Como seu nome sugere, ele é um protocolo de mensagem com suporte para a comunicação assíncrona entre as partes. Um protocolo de sistema de mensagens assíncrono desacopla o emissor e o receptor da mensagem tanto no espaço quanto no tempo e, portanto, é escalável em ambientes de rede que não são confiáveis. Apesar de seu nome, ele não tem nada a ver com filas de mensagens, na verdade, ele usa um modelo de publicação e assinatura. No final de 2014, ele se tornou oficialmente um padrão aberto OASIS, com suporte nas linguagens de programação populares, usando diversas implementações de software livre.

Por que o MQTT

O MQTT é um protocolo de rede leve e flexível que oferece o equilíbrio ideal para os desenvolvedores de IoT:

  • O protocolo leve permite a implementação em hardware de dispositivo altamente restringido e em redes de largura da banda limitada e de alta latência.
  • Sua flexibilidade possibilita o suporte a diversos cenários de aplicativo para dispositivos e serviços de IoT.

Para entender por que o MQTT é tão adequado para desenvolvedores de IoT, vamos analisar por que outros protocolos de rede populares falharam em IoT.

Por que não usar algum dos outros inúmeros protocolos de rede

A maioria dos desenvolvedores já se acostumou aos serviços da Web HTTP. Então, por que não conectar os dispositivos de IoT aos serviços da web? O dispositivo poderia enviar seus dados como uma solicitação de HTTP e receber atualizações do sistema como uma resposta de HTTP. Esse padrão de solicitação e resposta tem algumas limitações graves:

  • O HTTP é um protocolo síncrono. O cliente espera que o servidor responda. Os navegadores da web têm esse requisito, mas o custo é a baixa escalabilidade. No mundo da IoT, a comunicação síncrona tem sido um problema devido ao grande número de dispositivos e à rede, muitas vezes não confiável e de alta latência. Um protocolo de mensagem assíncrono é muito mais adequado para aplicativos de IoT. Os sensores podem enviar leituras e permitir que a rede descubra o caminho e a sincronização ideais para entregar aos dispositivos e serviços de destino.
  • HTTP é unidirecional. O cliente precisa iniciar a conexão. Em um aplicativo de IoT, os dispositivos e sensores geralmente são clientes, o que significa que eles não podem receber comandos da rede passivamente.
  • HTTP é um protocolo de um para um. O cliente faz uma solicitação e o servidor responde. É difícil e caro transmitir uma mensagem a todos os dispositivos na rede, o que é um caso de uso comum em aplicativos de IoT.
  • HTTP é um protocolo pesado com muitos cabeçalhos e regras. Ele não é adequado para redes restringidas.

Pelos motivos citados acima, a maioria dos sistemas escaláveis de alto desempenho usam um barramento do sistema de mensagens assíncrono, em vez de serviços da web, para trocas de dados internas. Na verdade, o protocolo de sistema de mensagens mais popular que é usado em sistemas de middleware corporativos é chamado AMQP (Advanced Message Queuing Protocol). No entanto, no ambiente de alto desempenho, a capacidade de computação e a latência da rede geralmente não são uma preocupação. O AMQP foi criado para assegurar a confiabilidade e a interoperabilidade em aplicativos corporativos. Ele possui um rico conjunto de recursos, mas não é adequado para aplicativos de IoT com restrição de recursos.

Além do AMQP, existem outros protocolos populares de sistema de mensagens. Por exemplo, o XMPP (Extensible Messaging and Presence Protocol) é um protocolo de mensagem instantânea (IM) ponto a ponto. Ele é pesado em recursos com suporte para casos de uso de IM, como presença e anexos de mídia. Em comparação com o MQTT, ele requer muito mais recursos no dispositivo e na rede.

Então, como o MQTT consegue ser tão leve e flexível? Um importante recurso do protocolo MQTT é o modelo de publicação e assinatura. Como em todos os protocolos de sistema de mensagens, ele desacopla o publicador e o consumidor de dados.

O modelo de publicação e assinatura

O protocolo MQTT define dois tipos de entidades na rede: um message broker e inúmeros clientes. O broker é um servidor que recebe todas as mensagens dos clientes e, em seguida, roteia essas mensagens para os clientes de destino relevantes. Um cliente é qualquer coisa que possa interagir com o broker e receber mensagens. Um cliente pode ser um sensor de IoT em campo ou um aplicativo em um data center que processa dados de IoT.

  1. O cliente conecta-se ao broker. Ele pode assinar qualquer “tópico” de mensagem no broker. Essa conexão pode ser uma conexão TCP/IP simples ou uma conexão TLS criptografada para mensagens sensíveis.
  2. O cliente publica as mensagens em um tópico, enviando a mensagem e o tópico ao broker.
  3. Em seguida, o broker encaminha a mensagem a todos os clientes que assinam esse tópico.

Como as mensagens do MQTT são organizadas por tópicos, o desenvolvedor de aplicativos tem a flexibilidade de especificar que determinados clientes somente podem interagir com determinadas mensagens. Por exemplo, os sensores publicarão suas leituras no tópico “sensor_data” e assinarão o tópico “config_change”. Os aplicativos de processamento de dados que salvam os dados do sensor em um banco de dados de backend assinarão o tópico “sensor_data”. Um aplicativo de console administrativo poderia receber comandos do administrador do sistema para ajustar as configurações dos sensores, como a sensibilidade e a frequência de amostragem, e publicar essas mudanças no tópico “config_change”. (Consulte Figura 1.)

Figura 1. O modelo de publicação e assinatura do MQTT para sensores de IoT

Ao mesmo tempo, o MQTT é leve. Ele tem um cabeçalho simples para especificar o tipo de mensagem, um tópico baseado em texto e, em seguida, uma carga útil binária arbitrária. O aplicativo pode usar qualquer formato de dados para a carga útil como JSON, XML, binário criptografado ou Base64, desde que os clientes de destino possam analisar a carga útil.

Introdução ao desenvolvimento com MQTT

A ferramenta mais fácil para começar o desenvolvimento com MQTT é o módulo Python mosquitto, que faz parte do projeto Eclipse Paho e fornece SDKs e bibliotecas do MQTT em várias linguagens de programação. Ele contém um broker do MQTT que pode ser executado no computador local e ferramentas de linha de comandos que podem interagir com o broker usando mensagens. É possível fazer download e instalar o módulo mosquitto no website do mosquitto.

O comando mosquitto executa o broker do MQTT no computador local. Opcionalmente, é possível usar a opção -d para executá-lo em segundo plano.

$ mosquitto -d

Em seguida, em outra janela do terminal, é possível usar o comando mosquitto_sub para conectar-se ao broker local e assinar um tópico. Após a execução do comando, ele vai esperar e imprimir todas as mensagens que receber da assinatura, à medida que elas forem chegando.

$ mosquitto_sub -t "dw/demo"

Em uma outra janela do terminal, é possível usar o comando mosquitto_pub para conectar-se ao broker local e, em seguida, publicar uma mensagem em um tópico.

$ mosquitto_pub -t "dw/demo" -m "hello world!"

Agora, o terminal que executa o mosquitto_sub deverá exibir “hello world!” na tela. Você acabou de enviar e receber uma mensagem usando um broker do MQTT!

É claro que em um sistema de produção, não é possível usar um computador local como o broker. Nesse caso, é possível usar o Serviço da plataforma Internet das Coisas do IBM Bluemix, que é um serviço sob demanda e confiável que funciona como um broker do MQTT. (Leia mais sobre como esse serviço do Bluemix se integra e usa o MQTT como seu protocolo para comunicar-se com dispositivos e aplicativos na documentação do serviço.)

O nó Serviço da plataforma Internet das Coisas do IBM Bluemix funciona da seguinte forma.

  • No console do Bluemix, é possível criar uma instância do serviço da plataforma Internet das Coisas sob demanda.
  • Em seguida, é possível incluir dispositivos que possam conectar a instância de serviço usando o MQTT. Cada dispositivo terá um ID e um nome. Somente os dispositivos listados podem acessar o serviço, e o painel da plataforma Watson IoT relatará informações sobre tráfego e uso desses serviços, nos respectivos dispositivos.
  • Para cada cliente do dispositivo, o Bluemix designará um nome do host, um nome de usuário e uma senha para a conexão com a instância de serviço (o broker do MQTT). (No Bluemix, o nome de usuário sempre é use-token-auth e a senha é o token que é mostrado na Figura 2 para cada dispositivo conectado.)
Figura 2. Criando uma instância de serviço da plataforma Internet das Coisas no IBM Bluemix

Ao usar um broker remoto do MQTT, será necessário passar pela aprovação das credenciais de autenticação e de nome do host do broker para os comandos mosquitto_sub e mosquitto_pub. Por exemplo, o comando a seguir assina o tópico de demonstração no nosso serviço da plataforma Internet das Coisas com o nome de usuário e senha fornecidos pelo Bluemix:

$ mosquitto_sub -t "demo" -h host.iotp.mqtt.bluemix.com -u username -P password

Para conhecer mais opções de como usar as ferramentas do mosquitto e também de como usar a API do mosquitto para criar seus próprios aplicativos clientes do MQTT, consulte a documentação no website do mosquitto.

Agora que você já tem as ferramentas necessárias, vamos nos aprofundar no protocolo MQTT.

Entendendo o protocolo MQTT

O MQTT é um protocolo de ligação que especifica como os bytes de dados são organizados e transmitidos pela rede TCP/IP. Mas por motivos práticos, os desenvolvedores não precisam entender o protocolo de ligação. Basta saber que cada mensagem tem uma carga útil de comando e dados. O comando define o tipo de mensagem (por exemplo, uma mensagem CONNECT ou uma mensagem SUBSCRIBE). Todas as bibliotecas e ferramentas do MQTT oferecem maneiras simples de manipular essas mensagens diretamente e podem preencher automaticamente alguns campos necessários, como os IDs da mensagem e do cliente.

Primeiro, o cliente conecta-se ao broker enviando uma mensagem CONNECT. A mensagem CONNECT pede para estabelecer uma conexão do cliente com o broker. A mensagem CONNECT tem os parâmetros de conteúdo a seguir.

Tablela 1. Parâmetros da mensagem CONNECT
Parâmetro Descrição
cleanSession Esta sinalização especifica se a conexão é persistente ou não. Uma sessão persistente armazena todas as assinaturas e as mensagens possivelmente perdidas (dependendo do QoS) no broker. (Consulte Tablela 3 para obter uma descrição do QoS).
username As credenciais de autenticação e autorização do broker.
password As credenciais de autenticação e autorização do broker.
lastWillTopic Quando a conexão for encerrada inesperadamente, o broker publicará automaticamente uma mensagem de “último desejo” em um tópico.
lastWillQos O QoS da mensagem de “último desejo”. (Consulte Tablela 3 para obter uma descrição do QoS).
lastWillMessage A própria mensagem de “último desejo”.
keepAlive Este é o intervalo de tempo em que o cliente precisa efetuar ping no broker para manter a conexão ativa.

O cliente receberá uma mensagem CONNACK do broker. A mensagem CONNACK tem os parâmetros de conteúdo a seguir.

Tablela 2. Parâmetros da mensagem CONNACK
Parâmetro Descrição
sessionPresent Indica se a conexão já tem uma sessão persistente. Ou seja, a conexão já tem tópicos assinados e receberá a entrega de mensagens ausentes.
returnCode 0 indica sucesso. Outros valores identificam a causa da falha.

Depois que uma conexão for estabelecida, o cliente poderá enviar uma ou mais mensagens SUBSCRIBE ao broker para indicar que ele receberá mensagens do broker de determinados tópicos. A mensagem pode ter uma ou várias repetições dos parâmetros a seguir.

Tablela 3. Parâmetros da mensagem SUBSCRIBE
Parâmetro Descrição
qos A sinalização qos (qualidade de serviço ou QoS) indica com que consistência as mensagens neste tópico precisam ser entregues aos clientes.

  • Valor 0: não confiável, a mensagem é entregue no máximo uma única vez, se o cliente estiver indisponível no momento, ele perderá a mensagem.
  • Valor 1: a mensagem deve ser entregue pelo menos uma vez.
  • Valor 2: a mensagem deve ser entregue exatamente uma vez.
tópico Um tópico para assinar. Um tópico pode ter vários níveis separados pelo caractere barra. Por exemplo, “dw/demo” e “ibm/bluemix/mqtt” são tópicos válidos.

Depois que o cliente tiver assinado um tópico com sucesso, o broker retornará uma mensagem SUBACK com um ou mais parâmetros returnCode.

Tablela 4. Parâmetros da mensagem SUBACK
Parâmetro Descrição
returnCode Existe um código de retorno para cada um dos tópicos no comando SUBSCRIBE. Os valores de retorno são os seguintes.

  • Valores 0 a 2: sucesso como nível de QoS correspondente. (Consulte Tablela 3 para saber mais sobre QoS.)
  • Valor 128: falha.

Correspondendo à mensagem SUBSCRIBE, o cliente também poderá UNSUBSCRIBE (cancelar a assinatura) de um tópico ou de vários tópicos.

Tablela 5. Parâmetros da mensagem UNSUBSCRIBE
Parâmetro Descrição
tópico Este parâmetro pode se repetir para vários tópicos.

O cliente pode enviar mensagens PUBLISH ao broker. A mensagem contém um tópico e uma carga útil de dados. Em seguida, o broker encaminha a mensagem a todos os clientes que assinam esse tópico.

Tablela 6. Parâmetros da mensagem PUBLISH
Parâmetro Descrição
topicName O tópico no qual a mensagem é publicada.
qos O nível de qualidade de serviço da entrega da mensagem. (Consulte Tablela 3 para obter uma descrição do QoS).
retainFlag Esta sinalização indica se o broker reterá a mensagem como a última mensagem conhecida deste tópica.
carga útil Os dados reais na mensagem. Pode ser uma sequência de texto ou um blob binário de dados.

Dicas e soluções alternativas

O poder do MQTT é a simplicidade. Não há restrições quanto ao tipo de tópico ou de carga útil de mensagem que se pode usar. Isso permite alguns casos de uso interessantes. Por exemplo, considere estas questões:

Como executar mensagens de um para um com o MQTT? Ambas as partes podem concordar em usar um tópico que seja exclusivo para elas. Por exemplo, o nome do tópico pode conter os IDs dos dois clientes para garantir sua exclusividade.

Como um cliente transmite seu status de presença? O sistema pode concordar com uma convenção de nomenclatura para tópicos de “presença”. Por exemplo, o tópico “presence/client-id” pode conter as informações de presença do cliente. O cliente define a mensagem como true quando se conecta e false quando se desconecta. O cliente também pode configurar uma mensagem de last will como false para ser definida quando a conexão for encerrada. A mensagem pode ser retida pelo broker para que novos clientes possam ler o tópico e descobrir o status de presença.

Como proteger as comunicações? A conexão do cliente com o broker pode ser uma conexão TLS criptografada para proteger os dados em trânsito. Além disso, como o protocolo MQTT não impõe restrições quanto ao formato de dados da carga útil, o sistema pode concordar com um método de criptografia e um mecanismo de atualização de chave. Depois disso, todo o conteúdo na carga útil pode ser dados binários criptografados das mensagens JSON ou XML reais.

Conclusão

Neste artigo eu ofereci uma introdução técnica ao protocolo MQTT. Você aprendeu o que é o MQTT, por que ele é adequado para aplicativos de IoT e como começar a desenvolver aplicativos que usam o MQTT.

Em um de meus próximos artigos, vou mostrar como desenvolver uma solução de sensor de IoT completa com serviços de MQTT de backend e usando uma placa NodeMCU.

Recursos

Recursos para download

Temas relacionados

Fonte:  https://www.ibm.com/developerworks/br/library/iot-mqtt-why-good-for-iot/index.html

Dicas para proteger sua rede no auge do KRACK

KRACK

A vulnerabilidade KRACK recente almeja o link entre seu dispositivo eo ponto de acesso Wi-Fi, que provavelmente é um roteador em sua casa, seu escritório ou seu café favorito. Essas dicas podem ajudar a melhorar a segurança de sua conexão.

vulnerabilidade dos ataques KRACK tem agora mais de 48 horas e foi discutida em detalhes em vários sites relacionados à tecnologia , por isso não repito os detalhes técnicos do ataque aqui. Para resumir:

  • Uma falha no protocolo de handshake sem fio WPA2 permite que os atacantes cheirem ou manipulem o tráfego entre seu dispositivo e o ponto de acesso wi-fi.
  • É particularmente ruim para dispositivos Linux e Android, devido a formulação ambígua no padrão WPA2 ou a mal-entendidos durante sua implementação. Efetivamente, até que o SO subjacente seja corrigido, a vulnerabilidade permite que os atacantes forçam todo o tráfego sem fio a acontecer sem qualquer criptografia.
  • Esta vulnerabilidade pode ser corrigida no cliente, então o céu não caiu e o padrão de criptografia sem fio WPA2 não está obsoleto no mesmo sentido em que o padrão WEP é (não “conserta” esse problema mudando para o WEP).
  • As distribuições de Linux mais populares já estão sendo enviadas atualizações que corrigem essa vulnerabilidade no cliente, então aplique as suas atualizações de forma adequada.
  • O Android será correções de remessa para esta vulnerabilidade muito em breve. Se o seu dispositivo estiver recebendo correções de segurança do Android, você receberá uma correção antes. Se o seu dispositivo já não receber essas atualizações, essa vulnerabilidade específica é apenas uma outra razão pela qual você deve parar de usar dispositivos Android antigos e não suportados.

Dito isto, da minha perspectiva, o Wi-Fi é apenas um outro link na cadeia de infra-estrutura não confiável e, em geral, devemos evitar tratá-lo como um canal de comunicação confiável.

Wi-Fi como infra-estrutura não confiável

Se você está lendo este artigo de seu laptop ou seu dispositivo móvel, então sua cadeia de comunicação provavelmente se parece com algo assim:

Blank Network Diagram - Basics.png

O ataque KRACK visa o link entre o seu dispositivo eo ponto de acesso Wi-Fi, que provavelmente é um roteador em sua casa, seu escritório, sua biblioteca de bairro ou seu café favorito.

Diagrama de rede em branco - Onde Kracks acontece (1) .png

Na realidade, esse diagrama deve ser semelhante a este:

Diagrama de rede em branco - Em todo o lado (1) .png

Wi-Fi é apenas o primeiro link em uma longa cadeia de comunicação que acontece por canais que não devemos confiar. Se eu adivinhe, o roteador de Wi-Fi que você está usando provavelmente não recebeu uma atualização de segurança desde o dia em que foi montado. Pior ainda, provavelmente veio com credenciais administrativas padrão ou fácil de adivinhar, que nunca foram alteradas. A menos que você configure e configure esse roteador e você se lembre da última vez que você atualizou o firmware, você deve assumir que agora ele é controlado por outra pessoa e não pode ser confiável.

Passando o roteador Wi-Fi, entramos na zona de desconfiança geral da infra-estrutura em geral – dependendo dos níveis gerais de paranóia. Aqui temos fornecedores de internet e provedores, muitos dos quais foram capturados monitorando, alterando, analisando e vendendo nosso tráfego pessoal na tentativa de ganhar dinheiro extra com nossos hábitos de navegação. Muitas vezes, seus próprios planos de parcelamento de segurança deixam muito a desejar e acabam expondo nosso tráfego a olhos maliciosos.

Na Internet em geral, temos que nos preocupar com potentes atores de nível estadual com capacidade de manipular protocolos de rede principais para realizar programas de vigilância em massa ou executar filtragem de tráfego a nível do estado.

Protocolo HTTPS

Felizmente, temos uma solução para o problema da comunicação segura sobre o meio não confiável, e usamos todos os dias – o protocolo HTTPS criptografa nosso tráfego na Internet ponto a ponto e garante que podemos confiar em que os sites com os quais nos comunicamos são quem eles dizem que são.

As iniciativas da Fundação Linux, como o Let’s Encrypt, tornam mais fácil para os proprietários de sites em todo o mundo oferecer criptografia de ponta a ponta que ajuda a garantir que qualquer equipamento comprometido entre nossos dispositivos pessoais e os sites que estamos tentando acessar não importa.

Diagrama de rede em branco - HTTPS (1) .png

Bem … quase não importa.

DNS continua a ser um problema

Mesmo que possamos usar o HTTPS com segurança para criar um canal de comunicação confiável, ainda existe a chance de um invasor com acesso ao nosso roteador Wi-Fi ou a alguém que possa alterar nosso tráfego Wi-Fi – como é o caso do KRACK – pode nos engana em se comunicar com o site errado. Eles podem fazê-lo aproveitando o fato de que ainda confiamos muito no DNS – um protocolo não criptografado, facilmente falsificado da década de 1980 .

Diagrama de rede em branco - LOL DNS.png

DNS é um sistema que traduz nomes de domínio amigáveis ​​para humanos como “linux.com” em endereços IP que os computadores podem usar para se comunicar uns com os outros. Para traduzir um nome de domínio para um endereço IP, o computador consultaria o software resolver – geralmente executado no roteador Wi-Fi ou no próprio sistema. O resolvedor então consultaria uma rede distribuída de servidores de nomes “raiz” para descobrir qual sistema na Internet tem o que é chamado de informações “autoritativas” sobre o endereço IP que corresponde ao nome de domínio “linux.com”.

O problema é que toda essa comunicação ocorre por meio de protocolos não-autenticados, facilmente falsificados e de texto claro, e as respostas podem ser facilmente alteradas por atacantes para que a consulta devolva dados incorretos. Se alguém conseguir esconder uma consulta DNS e retornar o endereço IP errado, eles podem manipular onde o nosso sistema acaba enviando a solicitação HTTP.

Felizmente, o HTTPS tem muita proteção integrada para garantir que não seja fácil para alguém fingir ser outro site. O certificado TLS no servidor mal-intencionado deve corresponder ao nome DNS que você solicita e ser emitido por uma Autoridade de Certificação respeitável reconhecida pelo seu navegador. Se esse não for o caso, o navegador mostrará um grande aviso de que o host com o qual você está tentando se comunicar não é quem eles dizem que são. Se você vir esse aviso, seja extremamente cauteloso antes de optar por substituí-lo, pois você pode estar afastando seus segredos para as pessoas que os usarão contra você.

Se os atacantes tiverem o controle total do roteador, eles podem impedir sua conexão de usar o HTTPS em primeiro lugar, interceptando a resposta do servidor que instrui seu navegador a configurar uma conexão segura (isto é chamado de ” ataque de tira SSL ” ). Para ajudar a protegê-lo desse ataque, os sites podem adicionar um cabeçalho de resposta especial dizendo ao seu navegador que use sempre HTTPS quando se comunicar com eles no futuro, mas isso só funciona após sua primeira visita. Para alguns sites muito populares, os navegadores agora incluem uma lista codificada de domínios que sempre devem ser acessados ​​através do HTTPS mesmo na primeira visita.

A solução para a falsificação de DNS existe e é chamada DNSSEC , mas tem adotado uma adoção muito lenta devido a obstáculos importantes – reais e percebidos. Até que DNSSEC seja usado universalmente, devemos assumir que as informações de DNS que recebemos não podem ser totalmente confiáveis.

Use VPN para resolver o problema de segurança da última milha

Então, se você não pode confiar no Wi-Fi – e / ou o roteador sem fio no porão que provavelmente é mais velho do que a maioria dos seus animais de estimação – o que pode ser feito para garantir a integridade da comunicação “última milha”, a única Isso acontece entre o seu dispositivo e a Internet em geral?

Uma solução aceitável é usar um provedor VPN respeitável que estabeleça um link de comunicação seguro entre o seu sistema e sua infraestrutura. A esperança aqui é que eles prestam mais atenção à segurança do que o seu fornecedor de roteadores e seu provedor de Internet imediato, de modo que eles estão em melhor posição para garantir que seu tráfego esteja protegido contra o cheiro ou a falsificação de festas maliciosas. O uso da VPN em todas as suas estações de trabalho e dispositivos móveis garante que vulnerabilidades como ataques KRACK ou roteadores inseguros não afetem a integridade de sua comunicação com o mundo exterior.

Diagrama de rede em branco - VPN.png

A importante ressalva aqui é que, ao escolher um provedor VPN, você deve estar razoavelmente seguro de sua confiabilidade; Caso contrário, você está simplesmente negociando um conjunto de atores maliciosos para outro. Fique longe de qualquer coisa que ofereça “VPN grátis”, pois provavelmente estão ganhando dinheiro espionando você e vendendo seu tráfego para empresas de marketing. Este site é um bom recurso que permite que você compare vários provedores de VPN para ver como eles se empilham uns contra os outros.

Nem todos os seus dispositivos precisam ter uma VPN instalada neles, mas as que você usa diariamente para acessar os sites com suas informações pessoais privadas – e especialmente qualquer coisa com acesso ao seu dinheiro e sua identidade (governo, sites bancários, redes sociais, etc.) devem ser protegidos. A VPN não é uma panaceia contra todas as vulnerabilidades do nível de rede, mas definitivamente ajudará a protegê-lo quando estiver preso usando Wi-Fi inseguro no aeroporto, ou a próxima vez que uma vulnerabilidade tipo KRACK for descoberta.

Saiba mais em “O Guia Essencial de SysAdmin para a Segurança da Estação de Trabalho Linux” da Fundação Linux. Baixe o ebook gratuito e a lista de verificação agora!

Fontehttps://www.linux.com/blog/2017/10/tips-secure-your-network-wake-krack