Este post irá ajudá-lo a escrever regras de Snort eficazes para melhorar materialmente a sua postura de segurança. Começaremos com uma quebra de como uma regra é construída e depois exploraremos as melhores práticas com exemplos, a fim de capturar o maior número possível de atividades maliciosas, usando o menor número possível de regras.
Snort é um sistema de detecção de intrusão de rede de código aberto (NIDS) que fornece análise de pacotes em tempo real e é parte da solução STA da Coralogix. Se você é um cliente STA da Coralogix, certifique-se também de verificar meu post anterior sobre como editar as Regras do Snort no STA.
Anatomy of Snort Rules
Antes de mergulhar nas diferentes estratégias para escrever suas melhores regras de snort, vamos começar dissecando um exemplo de regra do Snort:
alert: diz ao Snort para relatar este comportamento como um alerta (é obrigatório nas regras criadas para o STA).
tcp: significa que esta regra só se aplicará ao tráfego no TCP.
any: neste contexto, significa “de qualquer porta de origem”, depois há uma seta ‘->’ que significa “uma conexão com” (não há um operador ‘<-‘, mas você pode simplesmente inverter os argumentos ao redor do operador. Você pode usar o operador ‘<>’ para indicar que a direção da conexão é irrelevante para esta regra), depois uma faixa de IP que indica o endereço IP de destino e, em seguida, a porta. Você pode indicar um intervalo de portas usando dois pontos como 0:1024, o que significa 0-1024. No parêntese redondo, há algumas diretrizes para definir a mensagem de alerta, metadados sobre a regra, assim como verificações adicionais.
msg: é uma diretiva que simplesmente define a mensagem que será enviada (para Coralogix no caso STA) no caso de um tráfego correspondente ser detectado.
flow: é uma diretiva que indica se o conteúdo que estamos prestes a definir como nossa assinatura precisa aparecer na comunicação para o servidor (“to_server”) ou para o cliente (“to_client”). Isto pode ser muito útil se, por exemplo, gostaríamos de detectar a resposta do servidor que indica que ela foi violada.
established: é uma diretiva que fará com que o Snort limite sua busca por pacotes que correspondam a esta assinatura a pacotes que fazem parte de conexões estabelecidas apenas. Isto é útil para minimizar a carga no Snort.
uricontent: é uma diretiva que instrui o Snort a procurar por um certo texto no conteúdo normalizado HTTP URI. Neste exemplo, estamos procurando por uma url que é exatamente o texto “/root.exe”.
nocase: é uma diretiva que indica que gostaríamos que o Snort conduzisse uma pesquisa insensível a casos.
classtype: é uma diretiva que é um atributo de metadados indicando que tipo de atividade esta regra detecta.
reference: é uma diretiva que é um atributo de metadados que se liga a outro sistema para mais informações. No nosso exemplo, o valor url,<https://….> links para uma URL na Internet.
sid: é uma diretiva que é um atributo de metadados que indica o ID da assinatura. Se você estiver criando sua própria assinatura (mesmo que você esteja apenas substituindo uma regra incorporada), use um valor acima de 9.000.000 para evitar uma colisão com outra regra pré-existente.
rev: é uma diretiva que indica a versão da regra.
Há muito mais para aprender sobre regras do Snort que suportam análise de RegEx, análise de protocolos específicos (assim como uricontent para HTTP), procura por dados binários (não textuais) usando valores hexadecimais de bytes, e muito mais. Se você gostaria de saber mais você pode começar aqui.
Best Practices to Writing Effective Snort Rules
- Atenha a vulnerabilidade, não o exploit – Evite escrever regras para detectar um exploit específico porque existem inúmeros exploits para a mesma vulnerabilidade e podemos ter certeza de que novos estão sendo escritos enquanto você está lendo isto. Por exemplo, muitas das primeiras assinaturas para detectar ataques de overrun de buffer pareciam assim:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (content:"AAAAAAAAAAAAAA", msg:"Buffer overrun detected.")
A razão para isso é claro que para lançar um ataque de overrun de buffer bem sucedido, o atacante precisa preencher o buffer de uma certa variável e adicionar sua carga útil maliciosa no final para que ela se torne executável. Os caracteres que ele escolhe usar para preencher o buffer são completamente insignificantes e de facto, depois de tais assinaturas aparecerem, muitos toolkits de ataque simplesmente usaram uma letra ou letras diferentes para preencher o buffer e evadiram completamente este tipo de detecção de assinaturas. Uma maneira muito melhor seria tentar detectar este tipo de ataques detectando entradas incorretas nos campos com base em seu tipo e comprimento.
- Sua peculiaridade é seu melhor ativo, então use-a – Toda organização tem coisas que a tornam única. Muitas delas podem ser bastante úteis quando você tenta capturar atividades maliciosas na sua organização – tanto externas quanto internas. Ao usar este profundo conhecimento interno em seu benefício, você essencialmente converterá o problema de um problema tecnológico para um puro problema de inteligência da velha escola, forçando os atacantes a terem uma compreensão muito mais íntima de sua organização, a fim de serem capazes de esconder seus rastros de forma eficaz. Estas coisas podem ser de natureza tecnológica ou baseadas nos hábitos de trabalho particulares da sua organização e nas diretrizes internas. Aqui estão alguns exemplos:
- Horas de Trabalho Típicas: Algumas organizações em que trabalhei não permitiram que os funcionários trabalhassem de casa e a maioria dos funcionários já teria saído do escritório às 19:00. Para organizações similares, faria sentido colocar um alerta para notificá-lo de ligações do escritório após uma determinada hora. Um atacante que instalasse software malicioso na sua organização teria de saber esse comportamento e sintonizar o seu malware para comunicar com o seu Comando & Controlar servidores precisamente ao mesmo tempo, tais comunicações passariam despercebidas.
- Navegador típico: Suponha que sua organização tenha decidido usar o navegador Brave como seu navegador principal e ele seja instalado em cada novo laptop corporativo automaticamente e você tenha removido os atalhos do navegador IE/Edge de todos os seus laptops corporativos. Se este for o caso, uma conexão da organização, tanto para endereços internos como externos que usam um navegador diferente como o IE/Edge deve ser configurada para levantar um alerta.
- Intervalos de IP baseados em funções: Se for possível atribuir diferentes faixas de IP para diferentes servidores baseados em suas funções, por exemplo, ter todos os servidores DB em 192.168.0.0/24, os servidores web em 192.168.1.0/24, etc, então seria possível e até fácil configurar regras inteligentes baseadas no comportamento esperado de seus servidores baseados em suas funções. Por exemplo, servidores de base de dados normalmente não se conectam a outros servidores por conta própria, impressoras não tentam conectar-se aos seus controladores de domínio, etc.
- Tentativas de Conexão Inusitadas: Muitas organizações utilizam uma partilha pública num servidor de ficheiros para ajudar os seus utilizadores a partilharem ficheiros entre si e utilizam impressoras activadas pela rede para permitir que os seus utilizadores imprimam directamente dos seus computadores. Isso significa que os computadores clientes não devem conectar-se entre si, mesmo que você tenha (sabiamente) escolhido bloquear tal acesso em um firewall ou no switch, a própria tentativa de conectar de um cliente a outro computador cliente deve levantar um alerta e ser minuciosamente investigada.
- Portas Incomuns: Algumas organizações usam uma biblioteca especial para otimizar a comunicação entre serviços, de modo que toda comunicação HTTP entre servidores usa uma porta diferente das comuns (como 80, 443, 8080, etc). Neste caso, é uma boa idéia criar uma regra que seria acionada por qualquer comunicação nestas portas normalmente comuns.
- Honeytokens – Em um campo de batalha como a Internet onde todos podem ser qualquer um, engano, funciona tão bem para os defensores quanto funciona para os atacantes, se não melhor. Truques como renomear a conta de administrador embutida para um nome diferente e menos atraente e criar uma nova conta chamada Administrador que você nunca usará e criar uma regra de Snort para detectar se este nome de usuário, e-mail ou senha alguma vez são usados na rede. Seria quase impossível para os atacantes notarem que o Snort detectou suas tentativas de usar o falso usuário administrador. Outro exemplo é criar produtos, clientes, usuários e registros de cartão de crédito falsos no banco de dados e depois combinar as regras do Snort para detectá-los no tráfego da rede.
Esperamos que você tenha achado esta informação útil. Para mais informações sobre o Coralogix STA, verifique as últimas características que lançamos recentemente.