DevSecOps

10 fev, 2017

Retorno de protocolos não autenticados e não protegidos

Publicidade

As pessoas estão percebendo que ter um serviço inseguro, não autenticado e desprotegido rodando na Internet é uma má ideia. Quem iria saber, certo?

O que começou com um pedido de resgate de MongoDB está se espalhando rápido para novos serviços que são fáceis de “explorar” de forma semelhante.

Padrões inseguros

 Já foi coberto detalhadamente que os padrões de serviço são tremendamente importantes. Sou o tipo de admin de sistemas que gosta de ser explícito nas configurações dos servidores, não confiando nas configurações padrão. Alguns argumentam que isso não faz sentido e é uma perda de tempo, que os pacotes do sistema têm padrões bons e robustos.

Bem, aqui vai um pequeno segredo sobre pacotes: os que criam os pacotes não são necessariamente os mesmos que desenvolveram o software. Normalmente é um trabalho voluntário, ajudando outros com bons pacotes  RPM ou DEB para utilizarem. E mesmo que eu tenha certeza de que alguns pacotes fazem um esforço razoável para criar valores padrão seguros, eles podem estar deixando passar alguns pontos importantes.

Experiência do usuário vs. Segurança

Caso em questão: se você instalar o Memcached em uma máquina Red Hat ou CentOs, ele vai automaticamente ouvir todas as interfaces.

Super conveniente, já que a maioria dos usuários executa seus serviços Memcached em servidores diferentes. É uma boa interface de usuário. Mas como o Memcached é um protocolo não autenticado, ele também permite que qualquer um se conecte à sua instância Memached e ler ou escrever dados nela, apagar o cache… se não estiver apropriadamente protegido.

Onde nós deveríamos trocar a experiência do usuário pela segurança? Para uma tecnologia se tornar amplamente adotada, a experiência do usuário é discutivelmente mais importante. No entanto, conforme a adoção cresce, todos percebem rapidamente que a segurança deveria ter sido a prioridade.

Protegendo os dados

Os servidores de MongoDB ao redor do mundo têm sido “sequestrados”. Os invasores já se moveram para outros serviços, como Redis e ElasticSearch.

Eu sinto que é incrivelmente importante salientar que eles são motores de armazenamento de dados. São bancos de dados. Eles armazenam os dados da sua empresa e do seu cliente. Esse é o seu negócio.

Se você for proteger qualquer serviço, é melhor que sejam os que armazenam todos os dados.

O que vem depois?

Como um invasor, o que mais você poderia sequestrar? Ou, dito diferente, que outros serviços armazenam dados do cliente que valem a pena extrair?

Vou te dar algumas ideias:

  • Cassandra
  • RabbitMQ, ActiveMQ, ZeroMq…
  • Beanstalkd
  • Collectd
  • Longtash
  • Neo4j

Note que a maioria desses serviços tem suporte para autenticação; ele só precisa ser configurado explicitamente.

Aumentando a consciência

De uma forma, esses ataques tiveram um lado positivo: eles aumentam a consciência para o problema agudo que é um serviço sem autenticação e sem segurança.

Não há nada de errado com um protocolo que não suporte autenticação. Ele provavelmente faz isso por uma boa razão (simplicidade, performance, …).

Também não há nada errado com sistemas sem segurança, alguns só precisam disso (think webservers, servidores de e-mail,…).

Mas existe um problema quando eles são combinados e começam a armazenar dados importantes da empresa.

É quase como se uma geração inteira de novos administradores de sistemas tivesse ficado online, começado alguns serviços aqui, outros ali, e encerrado um dia. Não é o que os administradores de sistema realmente fazem. Isso pode ser algo que os desenvolvedores podem fazer quando falta tempo ou recursos para contratar administradores de sistema dedicados.

Vamos torcer para que esses ataques recentes causem uma mudança nesses serviços e destaquem a necessidade de administradores de sistemas habilidosos e serviços gerenciados.

***

Mattias Geniar faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: https://ma.ttias.be/return-unauthenticated-unfirewalled-protocols/.