# Explicador de vetores DoS e perfis AFM > Cada vetor DoS do AFM explicado nas palavras da própria F5, com a mecânica de limiares detalhada e a configuração verificada: a inversão silenciosa de mitigação abaixo da detecção, a semântica do modo automático, policiamento sem detecção e a interação com SYN cookies. Somente configuração defensiva. - Tool: https://ronutz.com/pt-BR/tools/f5-dos-vector-explainer - Family: Redes --- # Explicador de vetores DoS / perfis AFM Uma configuração de device-DoS do BIG-IP AFM - Advanced Firewall Manager é uma centena de pequenos ajustes com três modos de falha: limiares que nunca disparam, limiares que disparam em silêncio e limiares que alguém definiu sem saber o que o vetor realmente conta. Esta ferramenta lê a configuração de volta para você do jeito que o manual de referência leria. Cole uma estrofe `security dos device-config`, uma ou mais estrofes `security dos profile`, ou ambas, exatamente como o tmsh as lista. Cada entrada de vetor vira um cartão: a identidade do vetor na descrição de uma linha da própria F5 (a ferramenta carrega a tabela completa de 105 vetores da referência tmsh, incluindo as variáveis sys-db ajustáveis), cada campo de limiar anotado com a semântica da referência, e observações determinísticas logo abaixo. A semântica importa mais do que parece. Um limiar de detecção em pps compara uma média de um minuto contra um valor absoluto; a variante percentual compara essa mesma média de um minuto contra uma linha de base de uma hora aprendida dinamicamente; e o limite interno de taxa é programado em hardware nas plataformas que o possuem, com pacotes inválidos sempre descartados de qualquer forma. A ferramenta explicita cada um desses pontos no campo em que se aplica. As observações são o objetivo. A verificação principal é a inversão sobre a qual a própria série de troubleshooting de SYN cookies da F5 alerta: um limite de mitigação abaixo do limiar de detecção limita o tráfego antes de qualquer ataque ser declarado, e os pacotes caem sem nenhum log de ataque. A ferramenta sinaliza isso nas duas famílias de nomes de atributos, device (`default-internal-rate-limit` vs `detection-threshold-pps`) e profile (`rate-limit` vs `rate-threshold`), e repete a checagem por origem para as taxas de bad-actor. Ao redor dela: o modo automático explicado como o material de treinamento de DDoS o declara (limiares de detecção se ajustam ao tráfego observado; limites de mitigação são sempre guiados por estresse medido, então anomalias sem estresse alertam mas não bloqueiam), números manuais marcados como inertes sob o modo automático, `simulate-auto-threshold` restrito ao modo manual como a referência exige, detecção desabilitada enquanto um limite finito policia em silêncio, `enforce disabled` e `detect-only` apontados como monitoramento em vez de mitigação, e fiação de bad-actor órfã em qualquer direção. Um único nome de vetor renderiza um cartão; a palavra `vectors` renderiza o catálogo inteiro agrupado em nove categorias. Vetores fora da tabela curada ainda são interpretados e recebem a mecânica de limiares, sinalizados honestamente como fora dela em vez de adivinhados. Esta ferramenta explica configuração defensiva e nunca gera tráfego de nenhum tipo. Tudo roda localmente; nada do que você cola sai da página. ## Standards and references - [F5 TMSH Reference: security dos device-config (the vector-types table with per-vector descriptions and db tunables; the threshold parameter semantics; floor/ceiling; simulate scoping)](https://clouddocs.f5.com/cli/tmsh-reference/v13/modules/security/security_dos_device-config.html) - the curated catalogue's names and descriptions verbatim; the 1-minute/1-hour threshold semantics; the hardware rate-limit statement; bad-actor and blacklisting attributes - [F5 TMSH Reference: security dos profile (per-profile vector attributes: rate-threshold, rate-increase, rate-limit, state, per-source and per-destination controls, scrubbing defaults)](https://clouddocs.f5.com/cli/tmsh-reference/latest/modules/security/security_dos_profile.html) - the profile-context attribute names the parser and inversion check map - [F5 DDoS training labs: auto-thresholding behavior (detection thresholds adjust to observed traffic; mitigation limits are always stress-driven; anomalies without stress alert but do not block)](https://clouddocs.f5.com/training/community/ddos/html/class1/module1/lab6.html) - the automatic-mode explanation the auto-threshold observation quotes - [F5 DevCentral: SYN Cookie Troubleshooting - Logs (AFM Device DoS precedence over the LTM global SYN cookie; the mitigation-below-detection warning and its silent-drop consequence)](https://community.f5.com/kb/technicalarticles/9-syn-cookie-troubleshooting-logs/279431) - the tcp-half-open interplay notes and the inversion observation's operational consequence ## Related reading - [Políticas de Evicção de Conexões: O Que o BIG-IP Joga ao Mar, e Quando](https://ronutz.com/pt-BR/learn/bigip-connection-eviction-policies.md): A tabela de conexões é finita, e algo decide o que morre primeiro quando ela enche. Antes da 11.6 isso era o adaptive reaper e duas chaves de db; desde a 11.6 é a política de evicção: gatilhos de marca-d'água cujo significado muda com o contexto de anexação, estratégias que o manual honestamente chama de estatísticas e oportunistas, e um bloco de slow-flow com um padrão limpo de monitorar primeiro. - [Proteção contra SYN Flood no BIG-IP: Cookies, Limiares e Quem Responde Primeiro](https://ronutz.com/pt-BR/learn/bigip-syn-flood-protection.md): Um SYN flood ataca o estado half-open da tabela de conexões. A resposta do BIG-IP é o SYN cookie: um SYN-ACK sem estado com o estado codificado no número de sequência. A parte interessante é o empilhamento: limiares globais e por VS no LTM, cookies de hardware por VLAN e um vetor de device do AFM que tem precedência sobre tudo isso, mais um arranjo de limiares que mitiga em silêncio, sem log de ataque.