Em um dos artigos, falei sobre como o script infantil interfere na vida de nossos clientes. Neste artigo, gostaria de falar sobre soluções: como tentaremos lidar com isso.
Por enquanto, sem os códigos-fonte completos, eles estarão nos próximos artigos. Nesse ínterim, ao invés, sobre a estratégia e táticas de defesa.
"Soluções" padrão
Enviar reclamações
Uma abordagem muito comum. Se for detectada uma intrusão no seu IS, insira o invasor no firewall (ou não) e envie uma reclamação automática por e-mail, que foi encontrada no whois.
Recebemos reclamações sobre nossos clientes do sistema de detecção de intrusão de vários bancos, escritórios, sites. Mesmo, ao que parece, as grandes organizações apenas lançam o fail2ban e é isso.
Tudo funcionará com o tempo, e se o invasor não for banido? Sim, e é errado dar a oportunidade de bater à sua porta. E se alguém definir a senha do nível solarwinds123 e for hackeado na primeira tentativa?
Força os usuários a fazerem a coisa certa.
Você pode fazer seu próprio serviço, quase malware, como o Godaddy fez, adicionar outro usuário sob o login do nydys e esquecer de desabilitar o administrador do cloud-init, como o Godaddy fez, instalar 8 certificados extras no sistema, como o Godaddy fez.
Você também pode bloquear AD e outras "portas inseguras", como alguma outra hospedagem fez, e isso é tudo.
Você pode executar seus rastreadores e verificar suas próprias redes. Faça a varredura de portas, encontre serviços vulneráveis ou até mesmo tente invadir seus próprios clientes com as senhas quebradas com mais frequência.
Isso vai realmente ajudar em alguma coisa, mas o que e como deve ser organizado nos servidores do usuário deve ser decidido pelo usuário. Além disso, se você fizer tudo isso, como dizem, em uma escala, tropeçaremos em uma propagação do conhecimento técnico dos usuários e um mal-entendido: "Bem, o que eu fiz?!" e “Não sou um programador!”, mas todos devem estar seguros.
Lide com a segurança
Tudo acima é muito legal e pode ser útil. Mas os usuários precisam ser protegidos. Principalmente novatos. Os servidores virtuais costumam ser usados como um campo de experimentação, uma plataforma para se familiarizar com os sistemas de servidor e, às vezes, os usuários erram.
Conversamos com os donos das máquinas comprometidas, pedimos a eles que dissessem honestamente qual senha foi configurada e, infelizmente, logins e senhas do teste: teste ou nível 111: 111, ainda é uma prática comum.
Os usuários do Linux estão piorando, eles não estão tão dispostos a contatar como os usuários do Windows, embora, a julgar pelo número de reclamações sobre servidores Linux, eles sejam mais frequentemente hackeados ou usados por cibercriminosos.
É claro que nem todo mundo perde suas políticas e define senhas do nível "12345678" na raiz, mas isso acontece regularmente, então você deve tentar.
Arquitetura
Simples como um dorminhoco. Aqui está uma foto:
- O servidor trap coleta estatísticas por 1 hora e envia os dados coletados para o banco de dados.
- O servidor de juízes coleta dados do banco de dados e toma decisões sobre banimentos. Os banimentos também são registrados para o histórico médico de cada endereço IP específico.
- O servidor BGP analisa a lista de banidos gerada e transmite essa lista como um feed de BGP para os roteadores.
Dos servidores trap, os dados são enviados no mesmo formato pelo mesmo “Get-Bruteforce” que oferecemos anteriormente, a saber:
- Tentativas de hack
- Logins usados
- endereço de IP
- Registro PTR
Como as decisões são avaliadas
Estamos falando de uma solução potencialmente de combate, portanto, é impossível banir todos em uma fileira. É necessário introduzir critérios discretos e compreensíveis para que fique claro como, o quê e por quê.
No momento, 6 fatores são levados em consideração:
- Quantas vezes o atacante tentou invadir
- Quantas iscas diferentes ele acertou
- O endereço IP é estático
- O endereço IP pertence ao provedor de hospedagem ou doméstico?
- O invasor usou logins "ruins"?
- O que outros caras bons dizem
Expressões Quantitativas
Tudo está claro aqui. Quanto mais intensa for a pesquisa e quanto maior for sua área, e quanto maior for o dicionário, maior será a ameaça representada pelo invasor. Não adianta expandir este item.
PTR e tudo conectado a ele
Quando publicamos a análise de força bruta inicial, tornou-se perceptível que o registro do PTR diz muito.
O número de empresas de hospedagem chinesas atacando nossos servidores era simplesmente esmagador, mas isso não é exceção. Os clientes do Azure e AWS também participaram com muita alegria e não ocuparam os últimos lugares.
O maior número de ataques veio de endereços IP estáticos de provedores de hospedagem, então, se os servidores representam a maior ameaça à segurança, por que banir os usuários regulares?
Logins ruins
Há alguns. Por exemplo, do facilmente pesquisado "k8h3d" é o primeiro candidato a banimento. Este é um login de um worm cripto-minerador muito burro que deixou um backdoor no RDP com este nome de usuário. O mesmo se aplica a logins digitados em hindi, chinês e outros layouts que não são típicos de nossos clientes.
Você pode imaginar uma situação em que uma pessoa comete um erro em um dígito do endereço IP, não entra e começa a separar todas as senhas que havia em sua vida. Mas é difícil imaginar que nosso cliente comece a digitar algo diferente do Administrador padrão. Oferecemos sistema operacional apenas em logins em inglês, portanto, banir o layout do teclado é talvez o mais eficaz e seguro.
Outros caras bons
Spamhaus como um exemplo dos mocinhos, obrigado a eles pelas listas de bloqueio abertas. Digamos que um invasor atingiu apenas um honeypot, mas seu endereço está no SBL há muito tempo, então por que puxar?
É o mesmo com as listas fail2ban abertas, a opinião de outros mocinhos permite que você tome decisões com mais segurança.
Testando
Como na medicina. Estudo duplo-cego randomizado. Os servidores monitorados (exceto para traps) são divididos em dois grupos.
- Grupo de controle
- Os pacientes
Nas primeiras duas semanas, aplicamos regras de filtragem apenas para pacientes. O grupo de controle recebe todo o tráfego sem filtragem. Depois disso, exatamente metade dos servidores de ambos os grupos são trocados.
Grupos de controle adicionais serão localizados em outros CDs para levar em consideração a "sazonalidade" e excluir a influência de outros fatores, por exemplo, o fechamento de controladores, etc.
Assim, será possível estabelecer com mais segurança a eficácia do honeypotting como método de proteção de qualquer coisa além dos próprios honeypots.
Qual é o próximo?
Depois de coletar os dados primários, o teste de quase combate será realizado em apenas alguns data centers e, se isso reduzir significativamente o número de ataques, publicaremos:
- Abra a página de bloqueio com comentários expandidos nos formatos txt, xml e json
- Script para RouterOS e folha de bloqueio separada para RouterOS
- Feed aberto para roteadores com suporte BGP.
- Códigos-fonte.
Bem, se não houver menos ataques ou mais problemas, publicaremos apenas o código-fonte e um relatório sobre o motivo da queima.
Espero que o tópico seja tão interessante para você quanto está esperando por suas opiniões sobre o sistema proposto. Quaisquer ideias serão úteis.
