IDS no MS-DPC
Entendendo a proteção de cookies SYN em um MS-DPC
O cookie SYN é um mecanismo de proxy SYN sem estado que você pode usar em conjunto com outras defesas contra um ataque de inundação SYN. O cookie SYN é compatível com a placa multisserviços MS-DPC.
Como acontece com o proxy SYN tradicional, o cookie SYN é ativado quando o limite de ataque de inundação SYN é excedido. No entanto, como o cookie SYN é stateless, ele não configura uma sessão ou política e roteia buscas após o recebimento de um segmento SYN, e não mantém filas de solicitação de conexão. Isso reduz drasticamente o uso de CPU e memória e é a principal vantagem de usar cookies SYN em relação ao mecanismo de proxy SYN tradicional.
Quando o cookie SYN é habilitado no Junos OS e se torna o proxy de negociação de TCP para o servidor de destino, ele responde a cada segmento SYN de entrada com um SYN/ACK contendo um cookie criptografado como seu número de sequência inicial (ISN). O cookie é um hash MD5 do endereço de origem original e número de porta, endereço de destino e número de porta, e ISN do pacote SYN original. Após o envio do cookie, o Junos OS derruba o pacote SYN original e apaga o cookie calculado da memória. Se não houver resposta ao pacote que contém o cookie, o ataque é notado como um ataque SYN ativo e é efetivamente impedido.
Se o host de iniciação responder com um pacote TCP contendo o cookie +1 no campo TCP ACK, o Junos OS extrai o cookie, subtrai 1 do valor e recomputa o cookie para validar que ele é um ACK legítimo. Se for legítimo, o Junos OS inicia o processo de proxy do TCP configurando uma sessão e enviando um SYN para o servidor contendo as informações de origem do SYN original. Quando o Junos OS recebe um SYN/ACK do servidor, ele envia ACKs para o servidor e para o host de iniciação. Neste ponto, a conexão está estabelecida e o host e o servidor podem se comunicar diretamente.
O uso de cookies SYN ou proxy SYN permite que o dispositivo do roteador proteja os servidores TCP por trás dele contra ataques de inundação SYN em fluxos IPv6.
A Figura 1 mostra como uma conexão é estabelecida entre um host iniciador e um servidor quando o cookie SYN está ativo no Junos OS.
Configuração de regras de IDS em um MS-DPC
As regras de IDS configuradas com um MS-DPC identificam o tráfego para o qual você deseja que o software do roteador conte eventos. Como o IDS é baseado em propriedades de firewall stateful, você deve configurar pelo menos uma regra de firewall stateful e incluí-la no conjunto de serviços com as regras do IDS; para obter mais informações, veja Configuração de regras de firewall stateful.
Para configurar a proteção contra ataques de rede com um MS-MPC, consulte Configurando a proteção contra ataques de rede em um MS-MPC.
Para configurar uma regra de IDS, inclua a rule rule-name declaração no nível de [edit services ids] hierarquia:
[edit services ids] rule rule-name { match-direction (input | output | input-output); term term-name { from { application-sets set-name; applications [ application-names ]; destination-address (address | any-unicast) <except>; destination-address-range low minimum-value high maximum-value <except>; destination-prefix-list list-name <except>; source-address (address | any-unicast) <except>; source-address-range low minimum-value high maximum-value <except>; source-prefix-list list-name <except>; } then { aggregation (IDS) { destination-prefix prefix-value | destination-prefix-ipv6 prefix-value; source-prefix prefix-value | source-prefix-ipv6 prefix-value; } (force-entry | ignore-entry); logging { syslog; threshold rate; } session-limit { by-destination (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-pair (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-source (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } } syn-cookie { mss value; threshold rate; } } } }
Cada regra IDS consiste em um conjunto de termos, semelhante a um filtro configurado no nível de [edit firewall] hierarquia. Um termo consiste no seguinte:
fromdeclaração — especifica as condições e os aplicativos de correspondência que estão incluídos e excluídos.thendeclaração — especifica as ações e modificadores de ação a serem realizadas pelo software do roteador.
As seções a seguir descrevem o conteúdo da regra do IDS com mais detalhes:
- Configuração de direção de correspondência para regras de IDS
- Configuração de condições de correspondência nas regras do IDS
- Configuração de ações em regras de IDS
Configuração de direção de correspondência para regras de IDS
Cada regra deve incluir uma match-direction declaração que especifica se a correspondência é aplicada no lado de entrada ou saída da interface. Para configurar onde a correspondência é aplicada, inclua a match-direction (input | input-output | output) declaração no nível de [edit services ids rule rule-name] hierarquia:
[edit services ids rule rule-name] match-direction (input | output | input-output);
Se você configurar match-direction input-output, a criação de regras bidirecional será.
A direção de correspondência é usada em relação ao fluxo de tráfego por meio do AS ou pic de multisserviços. Quando um pacote é enviado para o PIC, as informações de direção são levadas junto com ele.
Com um conjunto de serviços de interface, a direção do pacote é determinada por se um pacote está entrando ou deixando a interface em que o conjunto de serviços é aplicado.
Com um conjunto de serviços de próximo salto, a direção de pacotes é determinada pela interface usada para encaminhar o pacote para o AS ou Multiservices PIC. Se a interface interna for usada para rotear o pacote, a direção do pacote é a entrada. Se a interface externa for usada para direcionar o pacote para o PIC, a direção do pacote será a saída. Para obter mais informações sobre interfaces internas e externas, consulte Configurando conjuntos de serviço a serem aplicados a interfaces de serviços.
No AS ou multisserviços PIC, uma busca por fluxos é realizada. Se nenhum fluxo for encontrado, o processamento de regras é realizado. Todas as regras do conjunto de serviços são consideradas. Durante o processamento de regras, a direção do pacote é comparada com as instruções de regra. Considera-se apenas regras com informações de direção que correspondam à direção do pacote.
Configuração de condições de correspondência nas regras do IDS
Para configurar as condições de correspondência do IDS, inclua a from declaração no nível de [edit services ids rule rule-name term term-name] hierarquia:
[edit services ids rule rule-name term term-name] from { application-sets set-name; applications [ application-names ]; destination-address (address | any-unicast) <except>; destination-address-range low minimum-value high maximum-value <except>; destination-prefix-list list-name <except>; source-address (address | any-unicast) <except>; source-address-range low minimum-value high maximum-value <except>; source-prefix-list list-name <except>; }
Se você omitir a from declaração, o software aceita todos os eventos e os coloca no cache de IDS para processamento.
O endereço de origem e o endereço de destino podem ser IPv4 ou IPv6. Você pode usar o endereço de destino, uma variedade de endereços de destino, um endereço de origem ou uma variedade de endereços de origem como condição de correspondência, da mesma forma que configuraria um filtro de firewall; para obter mais informações, veja as políticas de roteamento, filtros de firewall e guia de usuários de policiais de tráfego.
Alternativamente, você pode especificar uma lista de prefixos de origem ou destino, incluindo a prefix-list declaração no nível de [edit policy-options] hierarquia e, em seguida, incluindo a declaração ou source-prefix-list a destination-prefix-list declaração na regra do IDS. Por exemplo, veja Exemplos: Configuração de regras de firewall stateful.
Você também pode incluir definições de protocolo de aplicativo que você configurou no nível de [edit applications] hierarquia; para obter mais informações, veja Configurando propriedades de aplicativos.
Para aplicar uma ou mais definições específicas de protocolo de aplicativo, inclua a
applicationsdeclaração no nível de[edit services ids rule rule-name term term-name from]hierarquia.Para aplicar um ou mais conjuntos de definições de protocolo de aplicativo que você definiu, inclua a
application-setsdeclaração no nível hierárquico[edit services ids rule rule-name term term-name from].Nota:Se você incluir uma das declarações que especifica protocolos de aplicativo, o roteador deriva informações de porta e protocolo da configuração correspondente no
[edit applications]nível de hierarquia; você não pode especificar essas propriedades como condições de correspondência.
Se uma correspondência ocorrer em um aplicativo, o protocolo do aplicativo será exibido separadamente na show services ids saída de comando. Para obter mais informações, veja o CLI Explorer.
Configuração de ações em regras de IDS
Para configurar ações de IDS, inclua a then declaração no nível de [edit services ids rule rule-name term term-name] hierarquia:
[edit services ids rule rule-name term term-name] then { aggregation (IDS) { destination-prefix prefix-value | destination-prefix-ipv6 prefix-value; source-prefix prefix-value | source-prefix-ipv6 prefix-value; } (force-entry | ignore-entry); logging { syslog; threshold rate; } session-limit { by-destination (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-pair (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-source (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } } syn-cookie { mss value; threshold rate; } }
Você pode configurar as seguintes possíveis ações:
aggregation— O roteador agrega tráfego rotulado com os prefixos de origem ou destino especificados antes de passar os eventos para o processamento de IDS. Isso é útil se você quiser examinar todo o tráfego conectado com um determinado host de origem ou destino. Para coletar tráfego com algum outro marcador, como um aplicativo ou porta específico, configure esse valor nas condições de correspondência.Para configurar prefixos de agregação, inclua a
aggregationdeclaração no nível de[edit services ids rule rule-name term term-name then]hierarquia e especifique valores parasource-prefix,destination-prefix source-prefix-ipv6oudestination-prefix-ipv6:[edit services ids rule rule-name term term-name then] aggregation (IDS) { destination-prefix prefix-value | destination-prefix-ipv6 prefix-value; source-prefix prefix-value | source-prefix-ipv6 prefix-value; }
O valor e
source-prefixdestination-prefixdeve ser um inteiro entre 1 e 32. O valor esource-prefix-ipv6destination-prefix-ipv6deve ser um inteiro entre 1 e 128.(force-entry | ignore-entry)—force-entryoferece um lugar permanente em caches de IDS para eventos subsequentes após um evento ser registrado. Por padrão, o software IDS não registra informações sobre pacotes "bons" que não exibem comportamento suspeito. Você pode usar a declaração para registrar todo oforce-entrytráfego de um host suspeito, mesmo tráfego que de outra forma não seria contado.ignore-entrygarante que todos os eventos IDS sejam ignorados. Você pode usar esta declaração para ignorar todo o tráfego de um host em que confia, incluindo quaisquer anomalias temporárias que o IDS contaria como eventos.Para configurar um comportamento de entrada diferente do padrão, inclua a declaração ou
ignore-entryaforce-entrydeclaração no nível de[edit services ids rule rule-name term term-name then]hierarquia:[edit services ids rule rule-name term term-name then] (force-entry | ignore-entry);
logging— O evento está logado no arquivo de log do sistema.Para configurar o registro, inclua a
loggingdeclaração no nível de[edit services ids rule rule-name term term-name then]hierarquia:[edit services ids rule rule-name term term-name then] logging { syslog; threshold rate; }
Você pode incluir opcionalmente uma taxa de limite para acionar a geração de mensagens de log do sistema. A taxa de limite é especificada em eventos por segundo. Os logs IDS são gerados uma vez a cada 60 segundos para cada anomalia relatada. Os logs são gerados enquanto os eventos continuarem.
session-limit— O roteador limita as sessões abertas quando o limite especificado é atingido.Para configurar um limiar, inclua a
session-limitdeclaração no nível de[edit services ids rule rule-name term term-name then]hierarquia:[edit services ids rule rule-name term term-name then] session-limit { by-destination (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-pair (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-source (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } }
Você configura os limiares para limitação de fluxo com base na direção do tráfego:
Para limitar o número de sessões de saída de um host ou sub-rede interna, configure a
by-sourcedeclaração.Para limitar o número de sessões entre um par de endereços IP, sub-redes ou aplicativos, configure a
by-pairdeclaração.Para limitar o número de sessões recebidas a um endereço ou sub-rede IP público externo, configure a
by-destinationdeclaração.
Para cada direção, você pode configurar os seguintes valores limiar:
hold-time seconds— Quando aratemedição atingirpacketso valor limite, pare todos os novos fluxos pelo número especificado de segundos. Uma vezhold-timeem vigor, o tráfego é bloqueado pelo tempo especificado, mesmo que a taxa diminua abaixo do limite especificado. Por padrão,hold-timetem um valor de 0; o intervalo é de 0 a 60 segundos.maximum number— Número máximo de sessões abertas por endereço IP ou sub-rede por aplicativo. O intervalo é de 1 a 32.767.packets number— Número máximo de pacotes por segundo (pps) por endereço IP ou sub-rede por aplicativo. A faixa é de 4 a 2.147.483.647.rate number— Número máximo de sessões por segundo por endereço IP ou sub-rede por aplicativo. O intervalo é de 4 a 32.767.Se você incluir mais de um endereço de origem nas condições de correspondência configuradas no nível de
[edit services ids rule rule-name term term-name from]hierarquia, são aplicados limites para cada endereço de origem de forma independente. Por exemplo, a configuração a seguir permite 20 conexões de cada endereço de origem (10.1.1.1e), não10.1.1.220 conexões no total. A mesma lógica se aplica àsapplicationscondições edestination-addressàs condições compatíveis.[edit services ids rule rule-name term term-name] from { source-address 10.1.1.1; source-address 10.1.1.2; } then { session-limit by-source { maximum 20; } }Nota:Os limites de IDS são aplicados a pacotes que são aceitos por regras de firewall stateful. Eles não são aplicados a pacotes descartados ou rejeitados por regras de firewall stateful. Por exemplo, se o firewall stateful aceitar 75% do tráfego de entrada e os 25% restantes forem rejeitados ou descartados, o limite de IDS se aplica apenas a 75% do tráfego.
syn-cookie— O roteador ativa mecanismos de defesa de cookies SYN.Para configurar os valores de cookies SYN, inclua a
syn-cookiedeclaração no nível de[edit services ids rule rule-name term term-name then]hierarquia:[edit services ids rule rule-name term term-name then] syn-cookie { mss value; threshold rate; }
Se você habilitar defesas de cookies SYN, você deve incluir tanto uma taxa de limite para desencadear a atividade de cookies SYN quanto um valor máximo de tamanho de segmento (MSS) do Protocolo de Controle de Transmissão (TCP) para a vinculação de atraso do TCP. A taxa de limiar é especificada em ataques SYN por segundo. Por padrão, o valor de MSS do TCP é de 1500; o intervalo é de 128 a 8192.
Tratamento de ataques SYN Flood e proteção de cookies SYN
O principal objetivo de um ataque de inundação SYN é consumir todas as novas conexões de rede em um site e, assim, impedir que usuários autorizados e legítimos sejam capazes de se conectar a recursos de rede. O pacote SYN (sincronizar o número da sequência) é a primeira solicitação para se conectar enviado a um sistema. O pacote SYN contém uma ID à qual o receptor é necessário para responder. Se o pacote contém uma ID ilegal, o sistema de recebimento recebe um reconhecimento de conexão quando responde ao iniciador de conexão pretendido. Eventualmente, esse tempo de conexão semi-aberto e o canal de entrada no receptor ficam novamente disponíveis para lidar normalmente com outra solicitação. Um ataque de inundação SYN envia tantas solicitações desse tipo que todas as conexões recebidas estão continuamente vinculadas à espera de reconhecimentos que nunca são recebidos. Essa condição faz com que o servidor fique indisponível para usuários legais (exceto nos casos em que uma sessão de usuário seja estabelecida quando é exatamente no momento em que uma das conexões vinculadas está fora). Um ataque de inundação SYN é um ataque sem conexão. Ele não requer um endereço IP de origem real e, como usa endereços IP de destino legítimos ou endereços de porta, é praticamente impossível distinguir dos pacotes legítimos. Portanto, é muito difícil evitar esse tipo de ataque usando apenas filtros ou regras de firewall stateful. Basicamente, existem apenas três métodos para proteger desse tipo de ataque:
Intercept (ligação atrasada)— o firewall intercepta solicitações de sincronização de TCP recebidas e estabelece uma conexão com o cliente em nome do servidor e com o servidor em nome do cliente. Se ambas as conexões forem bem sucedidas, o firewall mescla de forma transparente as duas conexões. O firewall geralmente tem tempo limite agressivo para evitar que seus próprios recursos sejam consumidos por um ataque SYN. Esta é a solução mais intensiva em termos de processamento e requisitos de memória.
Assista (defesa SYN)— O firewall assiste passivamente conexões semi-abertas e fecha ativamente conexões no servidor após um período configurável de tempo.
Cookies SYN — os cookies SYN são opções específicas para o número inicial de sequência de TCP escolhido pelo servidor TCP. Um host que solicita uma conexão deve responder com o cookie para se conectar a uma tomada TCP aberta, enquanto um SYN-flood foi detectado como em andamento pelo IDS.
Os roteadores da Juniper Networks oferecem suporte à combinação de firewalls stateful e mecanismos de IDS para oferecer suporte aos métodos de cookie e relógio SYN (SYN defense). A chave para o ataque de inundação SYN é o preenchimento da fila SYN da vítima ou do elemento de rede atacado. O método de defesa de cookies SYN permite que a vítima continue aceitando solicitações de conexão quando a fila SYN estiver cheia ou, no caso dos aplicativos de firewall ou IDS, quando um determinado limiar tiver sido atingido. Após o limite ser atingido, um cookie criptográfico (um número de 32 bits) é criado a partir de informações no segmento SYN e o segmento SYN é descartado. O cookie é usado como o número de sequência inicial no SYN-ACK enviado ao cliente. O cookie (mais um) é devolvido ao firewall ou aplicativo IDS como o número de reconhecimento na ACK de um cliente legítimo. O cookie devolvido pode ser validado e as partes mais importantes do segmento SYN podem ser reconstruídas a partir do cookie, permitindo assim que uma conexão seja estabelecida. Como os clientes falsificados da inundação SYN nunca enviam ACKs, nenhum recurso é alocado para eles em nenhum estado quando os cookies SYN estão em uso. É preferível que você use contramedidas de inundação SYN apenas para hosts sob ataque. A tabela de anomalias pode ser usada para reconhecimento confiável de ataques ou elas podem ser habilitadas dentro do firewall stateful. Esse tipo de configuração também ajuda a evitar o esgotamento dos recursos do sistema (especialmente a tabela de fluxo) em caso de ataques.
Ao combinar vários serviços, o caminho geral é um fator importante para consideração nas direções futuras e inversas. Isso é especialmente verdade quando o NAT é implantado para determinar se o endereço pré-NAT ou pós-NAT deve ser usado para combinar com uma regra. No caminho seguinte de uma interface LAN para uma interface WAN, o IDS e o firewall stateful são executados primeiro, depois o NAT e, finalmente, o IPSec. Essa sequência de processamento de serviços denota que o firewall stateful deve ser compatível em um endereço pré-NAT, enquanto o túnel IPSec é compatível com o endereço pós-NAT. No caminho de retorno, o pacote IPSec é processado primeiro, depois o NAT e, finalmente, o firewall stateful. Essa ordem de processamento ainda permite que o IPSec corresponda a um endereço público e ao firewall stateful para combinar em um endereço privado. Você deve configurar separadamente os serviços de firewall, NAT e IDS. O processamento de pacotes fica muito mais complicado quando o IPSec sobre GRE é implementado no roteador com outros serviços ativados. Esse comportamento ocorre porque o Junos OS trata pacotes GRE de forma única após o encapsulamento gre. Depois que um pacote é encapsulado em um pacote GRE, ele é marcado com uma interface de entrada como a interface de saída de próximo salto. Esse método de marcação faz com que os pacotes GRE sejam bloqueados se houver filtros de entrada ou serviços de entrada que não permitam esse serviço.
Os serviços do Junos OS oferecem suporte a um conjunto limitado de regras de IDS para ajudar a detectar ataques como a digitalização de portas e anomalias nos padrões de tráfego. Ele também oferece suporte a alguma prevenção de ataques limitando o número de fluxos, sessões e taxas. Além disso, ele protege contra ataques SYN implementando um mecanismo de cookies SYN. Como o serviço de detecção e prevenção de invasões (IDP) não oferece suporte a assinaturas de aplicativos de camada superior, uma abordagem eficaz contra ataques é que a proteção contra um ataque SYN pode ser configurada. A solução de IDP é em grande parte uma ferramenta de monitoramento e não uma ferramenta de prevenção essencial. Para evitar um ataque SYN, o roteador funcionará como um tipo de "proxy" SYN e utilizará valores de cookies. Quando esse recurso é ativado, o roteador responde ao pacote SYN inicial com um pacote SYN-ACK que contém um valor de cookie exclusivo no campo de números de sequência. Se o iniciador responder com o mesmo cookie no campo de sequência, o fluxo de TCP será aceito; se o respondente não responder ou se responder com o cookie errado, o fluxo cairá. Para ativar essa defesa, você deve configurar um limiar de cookies SYN. Para habilitar a defesa de cookies SYN, uma ação de regra IDS deve conter um limiar que indica quando o recurso deve ser habilitado e um valor MSS para evitar que o roteador gerencie fragmentos segmentados ao agir como um proxy SYN:
[edit] user@host# set services ids rule simple-ids term 1 then syn-cookie
Configuração de conjuntos de regras de IDS em um MS-DPC
Você pode usar rule-set a declaração para definir uma coleção de regras de IDS que determinam quais ações o software do roteador executa em pacotes no fluxo de dados. Isso é suportado na placa multisserviços MS-DPC. (Para configurar a proteção contra ataques de rede com um MS-MPC, veja Configuração da proteção contra ataques de rede em um MS-MPC.)
Você define cada regra especificando um nome de regra e configurando termos. Em seguida, você especifica a ordem das regras, incluindo a rule-set declaração no nível de [edit services ids] hierarquia com uma rule declaração para cada regra:
[edit services ids] rule-set rule-set-name { rule rule-name; }
O software do roteador processa as regras na ordem em que você as especifica na configuração. Se um termo em uma regra corresponder ao pacote, o roteador realizará a ação correspondente e o processamento de regra será interrompido. Se nenhum termo em uma regra corresponde ao pacote, o processamento continua à próxima regra no conjunto de regras. Se nenhuma das regras corresponde ao pacote, o pacote será descartado por padrão.
Exemplos: Configuração de regras de IDS em um MS-DPC
A configuração a seguir adiciona uma entrada permanente à tabela de anomalias IDS quando encontra um fluxo com o endereço de destino 10.410.6.2. Este exemplo é suportado na placa multisserviços MS-DPC. (Para configurar a proteção contra ataques de rede com um MS-MPC, veja Configuração da proteção contra ataques de rede em um MS-MPC.)
[edit services ids]
rule simple_ids {
term 1 {
from {
destination-address 10.410.6.2/32;
}
then {
force-entry;
logging {
threshold 1;
syslog;
}
}
}
term default {
then {
aggregation {
source-prefix 24;
}
}
}
match-direction input;
}
A configuração do IDS funciona em conjunto com o mecanismo de firewall stateful e depende muito das anomalias relatadas pelo firewall stateful. O exemplo de configuração a seguir mostra essa relação:
[edit services ids]
rule simple_ids {
term 1 {
from {
source-address 10.30.20.2/32;
destination-address {
10.30.10.2/32;
10.30.1.2/32 except;
}
applications appl-ftp;
}
then {
force-entry;
logging {
threshold 5;
syslog;
}
syn-cookie {
threshold 10;
}
}
}
match-direction input;
}
[edit services stateful-firewall]
rule my-firewall-rule {
match-direction input-output;
term term1 {
from {
source-address 10.30.20.2/32;
applications appl-ftp ;
destination-address {
10.30.10.2/32;
10.30.1.2/32 except;
}
}
then {
accept;
syslog;
}
}
}
O firewall stateful ou serviço NAT é usado para gerar os dados de entrada para o aplicativo IDS. Ao ativar e configurar um serviço IDS, você também deve habilitar um firewall stateful com pelo menos uma regra (aceitar ou descartar todo o tráfego). Quando o sistema está sob ataque, o firewall stateful envia a lista correta e completa de eventos de ataque para o sistema IDS. Em seu ambiente de rede, você pode garantir que o sistema esteja totalmente protegido contra uma série de ataques para que o sistema IDS reporte todos esses ataques. Você deve ter cuidado ao configurar o sistema a ser protegido contra todos os ataques e cenários de acesso não autenticados para que a largura de banda de tráfego que o sistema lida não seja sobrecarregada. Também é importante verificar a correlação entre as mensagens de syslog de firewall correspondentes aos ataques e tabelas de IDS. As tabelas de IDS devem ter o mesmo número ou um pouco menos de anomalias ou erros em comparação com as mensagens de syslog baseadas em firewall. Você pode usar os comandos de exibição apropriados para exibir as tabelas de IDS.
Uma regra padrão de firewall stateful pode ser tão simples quanto apenas permitir a iniciação de conexão da interface interna para a interface externa e descartar todos os outros pacotes. No entanto, em um ambiente de rede de palavras reais, as regras geralmente são mais complexas, como a configuração de apenas algumas portas de unidade tributária, o uso de gateways de camada de aplicativo (ALGs) para protocolos complicados e o uso de NAT para conexões de saída e hosts internos, como servidores HTTP. Portanto, é necessário também configurar o sistema conforme necessário para intertrabalho com regras simples e complicadas. Por exemplo, se um ataque SYN for direcionado a um endereço interno que é simplesmente descartado, nenhuma anomalia precisa ser relatada ao sistema IDS. No entanto, se o ataque SYN for direcionado para o servidor HTTP real, anomalias devem ser relatadas. O sistema IDS pode mitigar ataques SYN usando o recurso de defesa de cookies TCP SYN. Você pode habilitar a metodologia de proteção de cookies SYN estabelecendo um limite para SYNs por segundo para um determinado host e também um tamanho máximo de segmento (MSS). Como o sistema IDS usa o firewall stateful, uma regra de firewall deve ser definida no conjunto de serviços. Se você não configurar a from declaração em um firewall stateful (condição de correspondência de prazo de regra) no nível de [edit services service-set service-set-name stateful-firewall-rules rule-name term term-name] hierarquia, isso significa que todos os eventos serão colocados no cache IDS.
O exemplo a seguir mostra a configuração dos limites de fluxo:
[edit services ids]
rule ids-all {
match-direction input;
term t1 {
from {
application-sets alg-set;
}
then {
aggregation {
destination-prefix 30; /* IDS action aggregation */
}
logging {
threshold 10;
}
session-limit {
by-destination {
hold-time 0;
maximum 10;
packets 200;
rate 100;
}
by-pair {
hold-time 0;
maximum 10;
packets 200;
rate 100;
}
by-source {
hold-time 5;
maximum 10;
packets 200;
rate 100;
}
}
}
}
}