Get best of the week

Como não proteger seus sistemas na nuvem

Frequentemente, quando conto a alguém sobre vulnerabilidade, eles me olham como um louco com um sinal "Arrependam-se, pois o fim do mundo está próximo"!

Agora todo mundo está em pânico e tentando organizar um "controle remoto", cometendo erros simples, coletando todos os possíveis ancinhos, então decidi compartilhar algumas histórias dramáticas com a participação de hackers ciganos, CVEs abertos e profissionais, mas devops um pouco ingênuos. Obviamente, tive que omitir alguns detalhes ou mesmo distorcer intencionalmente, para não incomodar os clientes. Na maioria das vezes, essa não é uma prática do trabalho atual da Technoserv, mas deixe este post como um pequeno memorando sobre como não fazê-lo, mesmo que você realmente queira.

Como cercar o servidor


Havia um servidor no centro de dados. Uma velha escola, ferro, sem nenhum recipiente sofisticado e virtualização. Várias gerações de funcionários atrás, um dos desenvolvedores o configurou "temporariamente, para que apenas alguns arquivos grandes do projeto sejam aceitos". Ao mesmo tempo, a empresa realmente se preocupava com a segurança da informação, mas, como costuma acontecer, colegas do IS foram atender às necessidades dos negócios e concordaram com uma opção temporária com acesso total à Internet.

Felizmente, o servidor estava localizado na zona cinza da DMZ e não pôde se conectar diretamente aos serviços críticos do circuito interno. A 22ª porta foi estabelecida e, por dentro, eles adicionaram apenas alguns usuários locais com senhas individuais para efetuar login via ssh / sftp. O acesso por certificados foi considerado muito inconveniente. Em seguida, os desenvolvedores de outro projeto vieram em execução e pediram para ajudar a automatizar envios regulares do servidor da contraparte, porque "você tem um servidor conveniente com acesso coordenado à rede". Então de novo.

O resultado foi uma situação extremamente animada quando o servidor, que parecia temporário, não recebeu nenhuma atualização, mas vários processos de negócios já estavam vinculados a ele e vários terabytes de dados eram bombeados por mês.

Decidimos monitorá-lo, já que o servidor é muito importante e os gráficos da CPU têm imediatamente uma prateleira de 100%. Eles acertaram em resolver o problema: e havia um monte de processos aleatórios em nome do teste de usuário suspeito e um monte de memória que eles haviam consumido, e os logs tinham força bruta contínua de todo o mundo.

Antes de colocar o servidor no esquecimento, eles cutucaram os processos: lsof imediatamente mostrou os arquivos excluídos, mas não fechados, que ainda estavam pendurados na RAM. Infelizmente, não foi possível entender exatamente o que o invasor estava fazendo, mas era mais provável que o comportamento fosse como uma pessoa do que elaborar um script. Ao examinar um script na RAM, inserções como scanez clasa (digitalizando uma classe) em romeno ficaram muito satisfeitas:

#!/bin/bash
while["1"];do
class="
#168
"
classb="`seq 1 255`"
classb2=($classb)
num_classb=${#classb2[*]}
b=${classb2[$((RANDOM%num_classb))]}
classc="`seq 1 255`"
classc2=($classc)
num_classc=${#classc2[*]}
c=${classc2[$((RANDOM%num_classc))]}
classes=($class)
num_class=${#classes[*]}
a=${classes[$((RANDOM%num_class))]}
echo "scanez clasa ${a}.${b}"
./a ${a}.${c}
done

Até onde eu sei, nada de sério vazou (ou eles não me falaram sobre isso) e o atacante não conseguiu entrar no perímetro, mas desde então a empresa tem falado sobre hackers ciganos de ladrões de cavalos.

regras


  1. Não permita que soluções temporárias convenientes, mas inseguras sejam corrigidas na infraestrutura. Sim, eu sei que eles são inconsistentes, mas apenas suportam quarentena, mas apenas concordam quando você os removerá. Após quantos dias ou horas. E limpe sem demora. Bem, pelo menos diga aos outros, por favor. Afinal, o serviço exposto começa a ser interrompido em média em 20 minutos.
  2. Não mostre RDP ssh e puro para o exterior, é melhor fornecer acesso via VPN ou serviços de encapsulamento da web. Não sei por que, mas para eles, as pessoas são mais responsáveis ​​pelo conjunto de contas permitidas e suas senhas.
  3. ssh — . . ssh, .
  4. - — - fail2ban, , - . «» «». , . , , , — .
  5. , : « ?» .
  6. . . , , .

IP – , firewall !


Entendo perfeitamente que o NAT era uma muleta necessária que estragou a vida dos desenvolvedores e não permitiu a implementação de opções para conectar rapidamente nós um ao outro. No entanto, seu efeito colateral de ocultar a estrutura interna da rede é muito útil em termos de complicar um ataque automatizado regular. E sim, entendo muito bem que a opção mais correta é usar um firewall na lista de permissões para permitir explicitamente apenas as conexões necessárias. O problema é que, no mundo da luta contínua por insignificantes, como a configuração difícil de um firewall ou a proibição de Deus, o SELinux nunca tem tempo e orçamento. Em geral, eles interferem na depuração, reduzem o indicador crítico do tempo de colocação no mercado e não permitem que desenvolvedores e devops vivam em paz.

A situação se tornou ainda mais interessante quando a infraestrutura em nuvem, implantada automaticamente sob demanda, se tornou o padrão do setor. O fato é que a maioria das soluções em nuvem pressupõe que a proteção de um monte de contêineres e máquinas virtuais elevados esteja com o usuário final. Como regra geral, eles fornecem a infraestrutura, alocam endereços IP brancos e isso é tudo, em essência, eles fornecem um conjunto de recursos, e não soluções prontas. Por padrão, tudo está fechado, mas é inconveniente e, portanto, impede o desenvolvimento. Portanto, vamos abrir tudo e testaremos com calma, mas na produção faremos o que é certo.

Muitas vezes isso leva a casos engraçados. Eu assisti uma cópia um pouco pirata do famoso servidor MMORPG. Clãs, donat, discussões contínuas das mães e outras alegrias. Todos se perguntavam por que alguns personagens eram tão rápidos e geralmente onipotentes. Corri o nmap pelo intervalo de endereços mais próximo do servidor do jogo.

Descobriu-se que toda a infraestrutura, incluindo front-end, back-end e banco de dados, simplesmente bloqueava portas abertas para o mundo externo. E qual é a senha mais provável para o usuário sa se o banco de dados estiver acessível na Internet? Isso mesmo, também! Como resultado, a coisa mais difícil é descobrir a estrutura da tabela.

Uma história semelhante ocorreu com um cliente que abriu o acesso remoto ao painel de administração de uma máquina doméstica enquanto trabalhava em casa por um tempo. Naturalmente, o painel de administração estava sem autorização, pois era considerado um recurso interno seguro. E o cliente não se incomodou e acabou de abrir a porta para toda a Internet imediatamente.

E os servidores ELK abertos ao mundo aparecem toda semana. O que simplesmente não encontra em seu conteúdo. A partir de dados pessoais, terminando com números de cartão de crédito.

regras


  1. O firewall deve estar na lista de permissões. Em nenhum caso o back-end deve ser acessível a partir do exterior. E não hesite em perguntar aos contratados e funcionários remotos a partir de qual IP eles se conectarão. No final, um IP dedicado custa cerca de 150 r / mês, um desperdício viável para a oportunidade de trabalhar em casa.
  2. Sempre use HTTPS e autenticação completa, mesmo que sejam "apenas" máquinas de teste.
  3. Separe estritamente ambientes de teste e produtivos. Nunca, nunca use as mesmas contas nos dois ambientes.

Samba


Especialmente, fico feliz com o servidor Samba, que é tradicionalmente usado para organizar o acesso compartilhado aos recursos. Por que não configurar o acesso de convidado para colegas do departamento vizinho para trocar arquivos de forma conveniente?

Em uma pequena empresa, tudo correu bem até que não houvesse mais departamentos. Após algum tempo, foi necessário configurar o acesso a ramificações remotas. E uma solução completamente "razoável" era abrir o acesso ao samba de fora. Bem, todo mundo tem suas próprias senhas, o que poderia dar errado? Ninguém se lembrou do acesso de convidados até que uma parte tangível do disco rígido estava entupida com os dados de outra pessoa. Os scanners automáticos encontraram rapidamente um armazenamento gratuito de arquivos e o HDD começou a entupir rapidamente os arquivos criptografados de outra pessoa. E em um dos diretórios, encontramos durante a auditoria uma coleção de filmes selecionados para adultos com a participação de mais de 60 atrizes (e teve sorte de não ter 18 anos; caso contrário, ele teria voado das agências policiais).

achados


  1. Nunca compartilhe armazenamento sem uma VPN.
  2. samba ftp-. , .
  3. , , - .

,


Eu tinha um cliente que não entendia por que ele precisava gastar quantias adicionais em backup se tudo funcionasse para ele. Isto é caro. E ele está bem afinado. Como resultado, os funcionários que abrem e executam tudo em uma linha que são enviados para o correio detectaram com segurança um vírus de criptografia. Eles perderam a base 1C e só puderam restaurá-la graças ao arquivo em papel e a um contratado que uma vez copiou a base para si mesmo.

Conversei com o líder, expliquei os pontos-chave que precisam ser alterados na empresa para eliminar os riscos de perder a base. Ele assentiu durante a conversa e terminou com uma frase maravilhosa: “O projétil não atinge o mesmo buraco duas vezes. Agora não há nada a temer. " Ele recusou novamente os backups e, naturalmente, perdeu todos os dados no mesmo cenário seis meses depois.

regras


  1. , (- ). , .
  2. . - , .
  3. . . , helpdesk.

!


Na minha experiência, pequenas e médias empresas geralmente começam com o gerenciamento de contas de usuário totalmente manual. Quero dizer, o novo gerente de vendas entra na cova dos administradores barbudos, onde recebe solenemente um login, senha e acesso. Tudo isso funciona bem até que a empresa comece a crescer.

Aqui estão as pessoas que venderam tanques compostos. Eles recentemente mudaram de liderança e foi decidido realizar uma auditoria de segurança completa. Eles até nos trouxeram em uma excursão para mostrar a produção. O espetáculo é muito impressionante: em uma enorme oficina, grandes peças foram giradas, nas quais a fibra de vidro foi enrolada, enquanto os trabalhadores corriam com um balde de resina epóxi, manchando-o cuidadosamente sobre a peça.

Em um prédio separado, eles tinham uma ala administrativa, onde nos enterramos diretamente na organização da parte informativa da produção. À primeira vista, eles haviam organizado um esquema bastante lógico, quando o acesso ao banco de dados do cliente era fornecido apenas através de uma conta interna no AD com a aprovação do chefe. Quando uma pessoa saiu, ele examinou a lista de verificação, entregou equipamentos, cartões e a conta foi desativada. Tudo isso foi feito manualmente, pois os fundos para o gerenciamento completo da identidade não foram alocados.

No processo de auditoria, descobrimos que eles haviam implementado um portal auto-escrito há muitos anos, para que os vendedores pudessem receber remotamente os dados necessários sobre os clientes. Eles até começaram a migrar sua infraestrutura para a nuvem, mas no final pararam no meio do caminho devido a algumas dificuldades internas. Além disso, o AD não pôde ser integrado lá e as contas foram excluídas exatamente da mesma forma na lista de verificação após a demissão. Tudo parece estar normal, mas nos registros encontramos uma conta ativa de um certo Vasily, que foi demitido há vários anos e agora trabalhou com sucesso em uma empresa concorrente. Além disso, a julgar pelos logs, ele descarregava quase toda a base de clientes pelo menos uma vez por mês.

A conta foi imediatamente bloqueada e eles começaram a observar como uma pessoa era capaz de burlar os regulamentos internos. Acontece que Vasily primeiro obteve acesso ao portal como gerente de vendas e depois foi transferido para uma posição gerencial diretamente no workshop, após o qual ele saiu. Mas a lista de verificação para dispensa no workshop é completamente diferente e a desativação da conta no portal não foi listada lá. Embora, ao que parece, faça uma lista geral de controle de acesso em todos os sistemas e o problema possa ser evitado.

regras


  1. Se você tiver mais de 100 funcionários, considere a introdução de um sistema IDM completo.
  2. Descarte os dados não da folha de desvio, mas diretamente do departamento de pessoal. As demissões são diferentes e uma solução alternativa pode não trazer você.
  3. — . . , « , », , ( , , . .).
  4. « », - .
  5. . .
  6. . , — . .

?


Por alguma razão, a segurança da informação é tradicionalmente percebida como indivíduos hostis que correm atrás de todos com suas regulamentações chatas e interferem em seu trabalho. De fato, com todos os exemplos grotescos acima, eles são frequentemente encontrados em casos reais, e são os guardas de segurança e os administradores paranóicos que ajudam a evitá-los.

Apenas tente encontrar um idioma comum. Primeiro de tudo, os próprios funcionários do SI não devem se tornar vigias que se dedicam apenas a tornar o cérebro uma política de senha regular sem explicação. A abordagem correta é se reunir com desenvolvedores e desenvolvedores, mergulhar em seus problemas. Em seguida, desenvolva a opção de compromisso correta, que não apenas brilhará com acesso sem senha ao mundo externo, mas será conveniente de usar.

E os devops querem ser, às vezes, pelo menos um pouco paranóicos.
O texto foi preparado por Vladimir Chikin, chefe de tecnologia da informação da Technoserv Cloud .

More articles:


All Articles