Segurança : Cisco Firepower Management Center

A determinação do estado padrão para um Sourcefire forneceu a regra em uma política da intrusão

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este artigo discute como a equipa de investigação da vulnerabilidade (VRT) determina o estado da regra em políticas da intrusão do padrão, e como faz um dispositivo de Sourcefire determine o estado padrão apropriado para uma regra nova.

Contribuído por Nazmul Rajib e por chuveiros de Steven, engenheiros de TAC da Cisco.

Determinação do estado da regra em uma política padrão

Cada regra tem um campo dos metadata, com zero ou mais valores de política. Há atualmente seis valores de política possíveis:

  1. gota Segurança-IP
  2. alerta Segurança-IP
  3. gota equilibrado-IP
  4. alerta equilibrado-IP
  5. gota Conectividade-IP
  6. alerta Conectividade-IP

Se uma política IPS é descida por exemplo do Sourcefire-forneceu Segurança e política de conectividade equilibradas, o dispositivo gerenciado reage do modo inline, e uma regra tem um valor de política dos metadata da gota equilibrado-IP, a regra será ajustada para deixar cair e gerar eventos em sua política IPS. Se uma regra tem um valor de política de somente os Segurança-IP deixam cair, ele estarão desabilitados em sua política.

Nota: Se uma regra tem os valores de política múltipla especificados, por exemplo: gota da política Segurança-IP, gota da política equilibrado-IP, aparece em ambas as políticas. Se nenhum valor de política é especificado para uma regra dada, aparece em nenhumas políticas à revelia.

Se um dispositivo gerenciado está ajustado ao modo passivo, e uma política está ajustada para deixar cair, esta não tem nenhum efeito. O dispositivo gera simplesmente alertas. Se um dispositivo está no modo inline, e um valor de política está ajustado para deixar cair, a regra deixa cair pacotes à revelia. Se seu valor de política é ajustado para alertar, gera somente eventos, sem deixar cair.

Finalmente, na maioria dos casos, se um pacote é deixado cair, um alerta é gerado. Isto é verdadeiro a menos que a supressão dos alertas for configurada independentemente para uma regra dada.

Como faz Sourcefire determine um estado padrão apropriado, para uma regra nova

O estado padrão de uma regra é baseado em um número de fatores. Por exemplo:

Impacto

Pontos a serem considerados

Como é provavelmente que as tentativas estarão feitas para explorar esta vulnerabilidade, e que porcentagem de nossos usuários (clientes de Sourcefire e a comunidade mais larga do Snort) é provável ser vulnerável a esta vulnerabilidade?

Coisas a recordar

Uma vulnerabilidade do internet explorer com ataques conhecidos no selvagem tem um impacto muito mais alto do que por exemplo uma função de banco de dados de SAP que possa ser usada maliciosamente quando as permissões são configuradas impropriamente, ou um ataque de recusa de serviço complexo em um módulo obscuro do kernel (centro) de Linux. VRT faz um julgamento do impacto que começa com a contagem CVSS de uma vulnerabilidade, ajustando o como necessário com toda a informação adicional que nós pudermos possuir. Esta é a métrica a mais importante de tudo, porque nós permitiremos às vezes uma regra de outra maneira não conseguiríamos sobre girado/não conseguir o grupo deixar cair se o impacto é altamente bastante.

Desempenho

Pontos a serem considerados

Nós esperamos esta regra ser rápida ou lenta em uma rede “média”?

Coisas a recordar

Quando a velocidade de uma regra for inteiramente dependente do tráfego que está inspecionando, que faz o desempenho difícil medir, nós temos uma ideia geral do que constituem uma rede normal, e de como uma regra dada executa nessa rede normal. Nós igualmente sabemos que uma regra com, por exemplo, um único fósforo satisfeito que seja relativamente longo (6 ou mais bytes, tipicamente) e relativamente original (isto é “obscureJavaScriptFunction()”, e não "|00 00 00 00|" ou “GET/HTTP/1.1") avaliará mais rapidamente do que uma regra com um PCRE complexo, uma série das cláusulas as mais byte_test e/ou do byte_jump, etc. Com este conhecimento nós podemos determinar se uma regra será rápida ou lenta e toma aquela na consideração.

Confiança

Pontos a serem considerados

Como é provavelmente esta regra para gerar falsos positivos?

Coisas a recordar

Algumas vulnerabilidades exigem circunstâncias muito específicas, facilmente detectadas ao estam presente a fim ser exploradas, neste caso nós podemos estar muito seguros a que em qualquer altura que a regra associada ateia fogo, uma façanha viva são em andamento. Por exemplo, se há um excesso de buffer em um protocolo que tenha uma corda mágica original em um de posição fixa, e então um comprimento especificado que esteja a uma distância fixa longe dessa corda mágica, nós podemos estar seguros em nossa capacidade para encontrar a corda mágica e para verificá-la contra um valor conhecido para ver se há problemas. Em outros casos, os problemas são muito menos bem definidos; por exemplo, determinados ataques do envenenamento do esconderijo DNS podem ser indicados anormalmente por um número grande de respostas NXDOMAIN que vêm de um server em um determinado período de tempo. Em tal caso, a mera presença de uma resposta NXDOMAIN não é em si um indicador de uma façanha; é a presença muito de um número grande de tais respostas em um curto período de tempo que indique o problema. Desde que esse número será diferente para redes diferentes, o VRT é forçado para escolher um valor que deva trabalhar para a maioria de redes e liberar isso; contudo, nós não podemos ser 100% seguro isso, quando os fogos da regra, atividade mal-intencionada real estão ocorrendo.

Em último mas não de menor importância, quando outros fatores puderem ser considerados de vez em quando como relevantes, o impacto é rei no final do dia - certificando-se nossos clientes são protegidos contra as ameaças que são mais provável de ver no selvagem são nosso interesse principal.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 117891