Aprender

Conceitos de redes e segurança, explicados com clareza.

Explicações práticas dos conceitos por trás das ferramentas. Cada artigo é escrito para que você entenda de verdade, e não só para definir um termo.

Ler esta página como

Como você quer aprender?

Primeira vez aqui? Quatro pontos de partida

  • Faça o curso aberto de TCP/IPUm curso introdutório completo, com 178 slides e notas do apresentador, dos conceitos de roteamento ao IPv6, ao multicast, ao MPLS e ao VRRP; apresente direto no navegador.
  • Comece pelo assunto RedesEndereços, roteamento e os protocolos que todo o resto pressupõe: os artigos do assunto Redes, na ordem do índice.
  • Preparação para uma provaOs guias de certificação: os objetivos de cada prova mapeados para os artigos que os cobrem, com as lacunas indicadas onde existem.
  • Tem algo quebrado agoraA Prática: triagem, o método para incidentes e como ler uma mudança, escritos para a hora em que você precisa deles.

Histórias

A maioria dos artigos daqui responde a uma pergunta. Alguns fazem outra coisa: colocam outros artigos numa ordem que defende algo que nenhum deles diz sozinho. Uma lista por categoria ordena por assunto; estes se ordenam pelo argumento, por isso esta é a única página em que aparecem juntos.

Ver todas as 9 histórias

Em volta de Aprender

  • Séries de artigos Assuntos contados em ordem, a partir do artigo de abertura, com as partes que ainda vão sair já nomeadas.70 séries
  • A Prática Aprenda o trabalho, não só a tecnologia: triagem, o método para incidentes, como ler uma mudança.64 publicados
  • Os Papéis Quem faz o quê ao longo da cadeia de valor, e o que cada papel precisa saber.43 posições
  • Pessoas Os engenheiros, fundadores e autores por trás dos protocolos e das empresas.148 pessoas
  • O registro da indústria Como as empresas, os produtos e as ideias chegaram até aqui: linhagem, aquisições, datas.364 empresas
  • Onde a indústria aprende As empresas que a ensinam, com seus programas e certificações.37 instituições
  • As ferramentas Cada artigo leva às ferramentas que calculam o que ele explica, e as ferramentas apontam de volta para ele.

O índice independente de fabricante

Todos os 440 artigos independentes de fabricante, agrupados em 11 assuntos e listados na ordem de leitura de cada assunto; os 311 artigos sobre a plataforma de um único fabricante ficam nos hubs de fabricantes. Pule para um assunto, filtre, mude para a lista ou busque em Aprender acima.

Certificados e PKI (15)

ArtigoTemaResumo
Anatomia de um certificado X.509Certificados e PKIO que vive dentro de um certificado TLS, como os bytes ASN.1/DER são estruturados, o que as extensões v3 de fato controlam, e por que decodificar um certificado não é o mesmo que confiar nele.
PEM, DER e os formatos de arquivo de certificadoCertificados e PKIPor que o mesmo certificado vem em tantas formas de arquivo, o que PEM e DER de fato são, e o que .crt, .pem, .pfx e .p12 realmente contêm.
Requisições de assinatura de certificado e como certificados são emitidosCertificados e PKIO que uma CSR contém, por que sua chave privada nunca deixa sua máquina, como uma CA valida e emite, e como o ACME automatiza toda a troca.
Cadeias de certificados: a ordem, a âncora e o que as quebraCertificados e PKIUm certificado de servidor é só o último elo. Como um cliente monta o caminho do certificado final até uma raiz em que confia, por que a ordem da mensagem Certificate importa e o que o TLS 1.3 relaxou, por que a raiz normalmente fica de fora, como identificadores de chave e nomes ligam um certificado ao seguinte, o que pathLenConstraint, cA e keyCertSign proíbem, por que uma raiz com assinatura cruzada aparece numa cadeia como se fosse intermediária, e por que a mesma cadeia funciona num navegador e falha em outro. Com a RFC 5280, a RFC 8446, os Baseline Requirements e uma cadeia viva da Let's Encrypt.
Como a validação de certificados de fato funcionaCertificados e PKIOs passos que um cliente executa para decidir que um certificado é confiável: construir a cadeia, checar assinaturas e datas, casar o nome e impor restrições.
Revogação de certificados: CRL, OCSP e certificados de vida curtaCertificados e PKIPor que um certificado às vezes precisa ser cancelado antes de expirar, por que os sistemas clássicos de revogação funcionam mal, e por que a indústria está encolhendo os tempos de vida dos certificados em vez disso.
Authority Information Access: as URLs de OCSP e CA IssuersCertificados e PKIA extensão AIA carrega dois tipos de ponteiro: onde perguntar se um certificado foi revogado (OCSP) e onde buscar o certificado do próprio emissor (CA Issuers). Para que serve cada um, por que são fáceis de confundir e o que o inspetor mostra.
OCSP Must-Staple: como fechar a brecha do soft-failCertificados e PKIA checagem OCSP em tempo real tem uma fraqueza fatal: quando o respondedor está inacessível, os clientes geralmente prosseguem mesmo assim. O OCSP stapling e o sinalizador Must-Staple são a correção. O que a extensão TLS Feature declara, e o risco operacional que ela carrega.
A era dos 47 dias: como os tempos de vida dos certificados TLS estão encolhendoCertificados e PKIO cronograma SC-081v3 do CA/Browser Forum reduz a validade máxima de certificados TLS públicos de 398 para 47 dias até 2029, em três etapas. Quais são as fases, por que 47, e o que isso faz com o volume de renovações.
ACME: como os certificados se emitem e se renovam sozinhosCertificados e PKIComo o protocolo ACME automatiza a emissão de certificados de ponta a ponta: a conta, o pedido, os três tipos de desafio, o registro dns-01 que você publica e a etapa de finalizar e baixar que produz o certificado.
Janelas de validade: notBefore, notAfter e a antecedência da renovaçãoCertificados e PKIComo o tempo de vida de um certificado é definido por dois carimbos de tempo, como esse tamanho é medido contra o limite, por que validade não é o mesmo que tempo restante, e como escolher uma antecedência para a renovação.
Let's Encrypt: a CA gratuita e os seus rate limitsCertificados e PKIO que é o Let's Encrypt, por que os certificados dele duram pouco e como os rate limits (os limites de emissão) funcionam de verdade: os limites por domínio registrado e por conta, os limites por conjunto exato de nomes e por falha de autorização, e por que as renovações via ARI ficam isentas de todos eles.
Reutilização de DCV e SII: a cadência de validação por trás da renovaçãoCertificados e PKIEmitir um certificado significa provar o controle do domínio e, para OV/EV, a identidade da organização. A SC-081v3 encurta por quanto tempo essas provas podem ser reutilizadas, o DCV para 10 dias até 2029, o que remodela a renovação tanto quanto a validade.
Renovar antes da expiração: antecedência, ACME e ARICertificados e PKIPor que a renovação tardia causa quedas, como o ACME automatiza a emissão e a renovação, como a extensão ARI permite que uma AC guie a janela de renovação, e como escolher uma antecedência que deixe espaço para tentar de novo.
PKI pública e privada: quais certificados a SC-081v3 governaCertificados e PKIO cronograma dos 47 dias vincula apenas certificados TLS publicamente confiáveis. O que separa a PKI pública da privada, por que as ACs internas estão isentas, e como ler o veredito de conformidade do planejador para um certificado interno.

Codificação e dados (46)

ArtigoTemaResumo
A anatomia de uma URLCodificação e dadosWeb e HTTPToda URL é construída a partir do mesmo punhado de partes definidas pela RFC 3986: esquema, autoridade (userinfo, host, porta), caminho, query e fragmento. O que cada parte significa, como um parser as distingue e onde os limites realmente caem.
A gramática JSON: seis tipos e algumas regras estritasCodificação e dadosJSON é menor do que parece. O formato inteiro são seis tipos de valor e um punhado de caracteres estruturais, governados por regras mais estritas do que a maioria lembra: sem comentários, sem vírgulas finais e chaves que precisam ser strings entre aspas.
Bytes, pontos de código e UTF-8Codificação e dadosA diferença entre um caractere e um byte, por que existem o Unicode e o UTF-8, e o que isso tem a ver com o Base64.
JSON vs YAML: o que converte limpo e o que não converteCodificação e dadosO YAML foi projetado para que todo documento JSON também seja YAML válido, e é por isso que a conversão entre eles geralmente simplesmente funciona. A parte interessante são as bordas: comentários, âncoras, múltiplos documentos e tipos exclusivos do YAML que não têm equivalente em JSON.
O que o tempo Unix realmente éCodificação e dadosO tempo Unix é um único inteiro: o número de segundos desde 1970-01-01T00:00:00Z, a época (epoch). É independente de fuso horário, compacto e ordenável, e por isso sustenta quase todo relógio de sistema, linha de log e timestamp de API. Convertê-lo em uma data de calendário é pura aritmética.
Base64 e Base64URL, explicadosCodificação e dadosComo dados binários viram texto seguro para transmitir, por que existe o preenchimento e o que muda na variante segura para URL.
Coerção de tipos no YAML e o problema da NoruegaCodificação e dadosO YAML adivinha o tipo de todo escalar sem aspas, e seus palpites são surpreendentes: o código de país NO vira false, uma versão como 1.0 vira número, e um código com zeros à esquerda perde os zeros. Conhecer a regra é a chave para uma conversão segura.
Números JSON e a armadilha da precisãoCodificação e dadosO JSON não impõe limite ao tamanho ou à precisão de um número, mas a maioria dos parsers converte silenciosamente todo número para um float de 64 bits. Essa incompatibilidade corrompe silenciosamente inteiros grandes e decimais exatos, e por isso um formatador deveria preservar os dígitos originais.
Query strings: parâmetros, sinais de mais e chaves repetidasCodificação e dadosWeb e HTTPA parte de uma URL após o ponto de interrogação parece simples mas esconde ambiguidade real: como os parâmetros são separados, por que um sinal de mais às vezes significa espaço, como chaves repetidas se comportam e por que não há um único padrão governante.
Segundos, milissegundos, microssegundos, nanossegundos: como distinguir unidades de épocaCodificação e dadosO mesmo instante pode ser escrito como 1700000000, 1700000000000 ou maior, dependendo de o timestamp contar segundos, milissegundos, microssegundos ou nanossegundos. Confundi-los é um bug clássico. Quase sempre dá para saber qual é qual pela magnitude do número.
Base64URL e o alfabeto seguro para URLsCodificação e dadosPor que JWTs e PKCE usam um alfabeto Base64 diferente, os dois caracteres que mudam e o que acontece com o preenchimento.
Chaves duplicadas em JSON: legais, perigosas e dignas de detecçãoCodificação e dadosA sintaxe JSON permite que a mesma chave apareça mais de uma vez em um objeto, mas a especificação não diz o que isso significa. Parsers diferentes resolvem isso de formas diferentes, o que torna chaves duplicadas uma fonte silenciosa de bugs e até de problemas de segurança.
Codificação de URL e hosts internacionalizadosCodificação e dadosWeb e HTTPURLs são restritas a um pequeno conjunto de caracteres ASCII, então todo o resto é codificado. A codificação percent cuida de caminhos e queries; o punycode cuida de nomes de host não-ASCII. Como ambos funcionam, e por que hosts internacionalizados são uma preocupação de phishing.
JSON e YAML na prática: APIs, declarações e orquestraçãoCodificação e dadosA divisão não é aleatória: APIs e declarações máquina-a-máquina tendem a ser JSON, enquanto arquivos de orquestração e pipeline escritos por humanos tendem a ser YAML. Entender por que cada domínio escolheu o que escolheu explica quando converter entre eles é útil.
O problema do ano 2038Codificação e dadosUm inteiro de 32 bits com sinal só consegue contar segundos até 2147483647, que cai em 2038-01-19T03:14:07Z. Um segundo depois ele transborda e dá a volta para um número negativo, jogando os sistemas afetados de volta a 1901. É o sucessor mais silencioso do Y2K, e a correção é um inteiro mais largo.
Âncoras, aliases e merge keys em YAMLCodificação e dadosO YAML pode definir um valor uma vez e reutilizá-lo com uma âncora e um alias, e mesclar um mapping em outro com uma merge key. Nada disso existe em JSON, então a conversão expande e duplica tudo. Este artigo cobre a sintaxe, o que acontece na conversão, e a armadilha de negação de serviço que eles habilitam.
Escapes de string e Unicode em JSONCodificação e dadosDentro de uma string JSON, alguns caracteres precisam ser escritos como escapes, e qualquer caractere pode ser escrito como \uXXXX. As regras são poucas mas estritas, e a que pega as pessoas é como caracteres além do plano básico, como emoji, precisam de um par substituto (surrogate pair).
ISO 8601, RFC 3339 e a Data HTTPCodificação e dadosDepois que um timestamp Unix é convertido de volta em uma data humana, ele é escrito em um de poucos formatos de texto padrão. O ISO 8601 é o padrão amplo, o RFC 3339 é seu perfil estrito para a internet, e a data HTTP é a exceção. Saber a diferença evita muita dor de cabeça com parsing.
Onde o Base64 aparece: data URIs, MIME, PEM e Basic authCodificação e dadosOs lugares reais em que binário é embrulhado em texto, o custo de tamanho de fazer isso e por que Base64 em um cabeçalho de autenticação não é criptografia.
Base32, explicadoCodificação e dadosIdentidade e tokensPor que o Base32 troca tamanho por um alfabeto sem ambiguidades e insensível a maiúsculas, como funciona seu agrupamento de 5 bits, e onde ele aparece (segredos TOTP, endereços onion, DNS).
Block scalars e strings multilinha em YAMLCodificação e dadosO YAML tem duas formas de escrever uma string multilinha, e elas tratam quebras de linha de modo diferente: o estilo literal as mantém, o estilo folded as transforma em espaços. Indicadores de chomping então decidem o que acontece com a quebra de linha final. Errar isso é por que um script ou certificado embutido sai sutilmente corrompido.
Por que o tempo Unix ignora os segundos bissextosCodificação e dadosO UTC ocasionalmente insere um segundo bissexto para se manter alinhado com a rotação da Terra, mas o tempo Unix finge que todo dia tem exatamente 86.400 segundos. Essa simplificação deliberada significa que um timestamp Unix não é uma contagem verdadeira de segundos decorridos desde a época — e é a escolha certa para o tempo civil.
Vírgulas finais, comentários e a família JSON5Codificação e dadosO JSON estrito não tem comentários nem vírgulas finais, o que surpreende quem usa um editor que aceita ambos. A razão é que o JSON é um formato mínimo de interchange, e as variantes tolerantes (JSONC, JSON5) são coisas separadas. Saber qual é qual evita arquivos de config que quebram em outra ferramenta.
Codificação hexadecimal (Base16), explicadaCodificação e dadosComo o hexadecimal representa cada byte com dois caracteres, por que é a forma padrão de imprimir bytes brutos, e como ele se compara ao Base64 e ao Base32.
Formatação, minificação e JSON canônicoCodificação e dadosO espaço em branco não muda o que o JSON significa, então JSON identado e minificado são o mesmo dado. Mas quando o JSON é assinado ou hasheado, os bytes exatos importam, e é aí que entra o JSON canônico: uma forma determinística de serializar o mesmo dado exatamente na mesma string toda vez.
Números romanos: como o sistema realmente funcionaCodificação e dadosSete símbolos, nenhum zero e uma regra de subtração que chegou mil anos depois de Roma. Por que IIII está no seu relógio e IV está no livro didático, o que IL viola e por que o sistema clássico termina em 3999.
URLs relativas e como elas resolvemCodificação e dadosWeb e HTTPUma URL relativa deixa de fora o esquema e o host e é completada contra uma URL base. As regras de como um navegador preenche o resto, e como ./ e ../ e uma barra inicial mudam o resultado, explicam muitos links quebrados e algumas surpresas de segurança.
Aritmética de tempo e fusos horários: durações exatas, reuniões honestasCodificação e dadosPor que 'mais um mês' não tem resposta exata, o que as durações ISO 8601 realmente prometem e como um instante UTC vira quatro relógios de parede diferentes. A armadilha do horário de verão, a armadilha da mudança de data e o argumento para planejar reuniões com uma data real.
Codificação por porcentagem (codificação de URL), explicadaCodificação e dadosPor que as URLs escapam certos caracteres como %XX, quais caracteres é seguro deixar como estão, e em que a codificação por porcentagem difere do Base64.
URLs enganosas: como enxergar além dos truquesCodificação e dadosWeb e HTTPURLs são uma ferramenta favorita para phishing porque o destino real é fácil de disfarçar. O truque do userinfo, os parâmetros de redirecionamento e os caracteres parecidos, todos fazem um link hostil parecer amigável. Este artigo mostra os disfarces comuns e o único hábito confiável para encontrar o host real.
Base16, Base32, Base64 e codificação por porcentagem comparadasCodificação e dadosUm olhar lado a lado para as quatro codificações de texto: seus alfabetos, sobrecarga de tamanho, legibilidade, e quando recorrer a cada uma.
Como funciona o diff de textoCodificação e dadosTexto e utilitáriosUm diff encontra o menor conjunto de inserções e remoções que transforma um texto em outro. Por baixo está a maior subsequência comum: as linhas que as duas versões compartilham, na mesma ordem, formam a espinha dorsal inalterada, e todo o resto é uma adição ou uma remoção.
Como ler um diffCodificação e dadosTexto e utilitáriosComo ler um diff linha a linha: linhas inalteradas, adicionadas e removidas, os marcadores de mais e menos, os números de linha dos dois lados, o destaque palavra a palavra e o que ignorar espaços e ignorar maiúsculas realmente mudam. Mais o que um diff não consegue dizer.
Diffs em nível de palavra e de caractereCodificação e dadosTexto e utilitáriosUm diff de linha marca a linha inteira como alterada mesmo quando um único caractere mudou. Diffs em nível de palavra e de caractere destacam exatamente a parte da linha que mudou, o que é muito mais fácil de ler para prosa, linhas longas e edições pequenas. Este artigo cobre a diferença e quando cada lente é a certa.
Diffs de três vias e conflitos de mergeCodificação e dadosTexto e utilitáriosUm diff normal compara duas versões e não consegue dizer qual delas mudou. Um diff de três vias adiciona um ancestral comum, que é o que torna o merge automático possível e o que produz os marcadores de conflito <<<<<<< ======= >>>>>>>. Este artigo explica o terceiro insumo e como ler e resolver um conflito.
Edições mínimas: por que um diff pode parecer erradoCodificação e dadosTexto e utilitáriosUm diff mostra o menor conjunto de inserções e remoções que transforma um texto no outro. Como o menor conjunto não é único e o algoritmo precisa escolher, um diff pode alinhar linhas de formas contraintuitivas, culpando o bloco errado ou dividindo uma seção movida. Saber disso torna diffs estranhos legíveis.
Como ler a estrutura do XMLCodificação e dadosSegurança e WAFXML é uma árvore de elementos construída a partir de um punhado de partes: uma declaração opcional, elementos com atributos, texto e algumas construções especiais. Uma vez que você consegue nomear cada parte e ver como elas se aninham, ler um documento desconhecido de cima a baixo vira rotina em vez de um jogo de adivinhação.
Namespaces XML explicadosCodificação e dadosSegurança e WAFQuando dois vocabulários XML usam o mesmo nome de elemento para coisas diferentes, namespaces os mantêm separados vinculando um prefixo a uma URI única. O prefixo é apenas um atalho local; a URI é a identidade real. Entender essa divisão resolve a maior parte da confusão com namespaces.
XML bem formado vs válidoCodificação e dadosSegurança e WAFBoa formação é a linha de base do XML: uma raiz, tags aninhadas e correspondidas corretamente, atributos entre aspas e especiais escapados. Validade é uma afirmação mais forte e separada de que um documento também segue um schema. Um parser rejeita XML mal formado de imediato, que é por que estas regras vêm primeiro.
CDATA, comentários e instruções de processamentoCodificação e dadosSegurança e WAFNem tudo em XML é um elemento. Seções CDATA guardam texto cru que de outra forma precisaria de escape, comentários anotam sem afetar o conteúdo, e instruções de processamento carregam direções para uma aplicação. Reconhecer estas três impede que pareçam ruído misterioso.
Os formatos do meio: por que todo defeito de intercâmbio é o mesmo defeitoCodificação e dadosJSON, YAML, XML, carimbos de tempo, codificações de texto, base64, URLs, diffs. Parecem assuntos separados com páginas de referência separadas. São um assunto só: cada um é uma convenção para pôr significado numa cadeia de caracteres de modo que outra coisa consiga tirá-lo de volta, e quase todo defeito do conjunto é as duas pontas discordando sobre o que saiu.
Formulários HTML e codificação de requisições: como a web despacha sua entradaCodificação e dadosWeb e HTTPUm formulário é um contrato entre página e servidor: quais campos, qual verbo, qual formato de fio. GET põe as respostas na URL; POST põe no corpo; e o enctype escolhe o dialeto do corpo - as correntes chave=valor do urlencoded, as partes delimitadas por boundary do multipart, feitas para arquivos. O que cada escolha significa para logs, caches, limites de tamanho e depuração, mais a nota da era fetch: o FormData manteve os formatos vivos depois que formulários deixaram de ser o único remetente.
URI, URL, URN: qual é mesmo a diferença?Codificação e dadosWeb e HTTPAs três siglas que todo mundo usa como sinônimo codificam uma ideia limpa: identificar vs localizar vs nomear. URI é o guarda-chuva - qualquer identificador na gramática padrão; URL é o identificador que também diz onde e como buscar; URN era o esquema para nomes puros, sem localização (urn:isbn:...). Por que o próprio W3C declarou a tricotomia clássica obsoleta, o que 'URI' significa em especificações vs 'URL' na conversa, e a lição de nomes que este site vive colecionando.
Unicode: pontos de código, planos, nomes e propriedadesCodificação e dadosO que é um ponto de código, como os 1.114.112 deles se organizam em planos, por que um caractere na tela pode ser vários pontos de código, como o Unicode nomeia e classifica cada caractere, e por que o mesmo emoji mede 1, 2, 4 ou 4 conforme a linguagem que conta.
UTF-8, UTF-16 e UTF-32, byte por byteCodificação e dadosWeb e HTTPComo cada codificação do Unicode distribui um ponto de código em bytes, como reconhecer cada uma num dump hexadecimal, quais sequências de bytes são malformadas e exatamente o que um decodificador substitui por U+FFFD, e o que faz uma marca de ordem de bytes, incluindo o ponto em que um navegador e o padrão Unicode discordam.
Mojibake: por que café vira café, e como recuperar o textoCodificação e dadosWeb e HTTPO texto fica embaralhado quando bytes gravados num charset são lidos em outro. Como surgem os padrões clássicos (UTF-8 lido como windows-1252, arquivos do DOS e do Windows lidos um como o outro, EBCDIC lido como Latin-1), por que o navegador lê Latin-1 como windows-1252, como um único caractere invisível no rótulo do charset embaralha uma página inteira, como desfazer o estrago e quando isso não é possível, e o que a codificação de uma política de WAF do BIG-IP tem a ver com tudo isso.

Hashing e cripto (15)

ArtigoTemaResumo
Hash, criptografia e codificação: três coisas diferentesHashing e criptoCodificação e dadosTrês operações constantemente confundidas, separadas de forma limpa por duas perguntas: é reversível e precisa de uma chave?
Hash criptográfico: SHA-256 e a família SHA-2Hashing e criptoO que uma função de hash garante, as propriedades que a tornam criptográfica e por que um resumo não é criptografia.
Como escolher um hash: MD5, SHA-1, SHA-2, SHA-3 e BLAKEHashing e criptoQuais funções de hash ainda são seguras, quais estão quebradas, quais são seus tamanhos de saída e como escolher a certa.
Colisões, resistência à pré-imagem e o limite do aniversárioHashing e criptoAs três propriedades de segurança que um hash criptográfico deve ter, por que colisões importam e a matemática do aniversário que define a força real.
Como armazenar senhas: bcrypt, scrypt e Argon2Hashing e criptoPor que um hash rápido como o SHA-256 é a ferramenta errada para senhas, e o que o sal e os fatores de trabalho de fato fazem.
HMAC: hash com chave para autenticação de mensagensHashing e criptoIdentidade e tokensPor que um hash simples prova integridade mas não autenticidade, como uma chave secreta resolve isso e por que a estrutura do HMAC importa.
Por que HMAC, e não hash(chave + mensagem)Hashing e criptoO ataque de extensão de comprimento que quebra o hashing com chave ingênuo, e a construção aninhada que o HMAC usa para derrotá-lo.
Como autenticar requisições de API com HMACHashing e criptoComo um segredo compartilhado e um hash permitem que um servidor confie numa requisição que ele não viu ser feita, e onde entra a proteção contra replay.
Como verificar um HMAC com segurança: tempo constante e repetiçãoHashing e criptoPor que comparar assinaturas com == vaza um canal lateral de tempo, e por que uma assinatura válida sozinha não impede uma requisição repetida.
Por que hashes criptográficos são de mão únicaHashing e criptoUm hash criptográfico mapeia qualquer entrada para um resumo de tamanho fixo e é projetado para que recuperar a entrada a partir do resumo seja inviável. Essa propriedade, resistência à pré-imagem, é o motivo pelo qual você não pode descriptografar um hash. Só há duas formas de revertê-lo: consultar uma tabela ou tentar e verificar — ambas são busca, não inversão.
Força bruta vs tabelas de consulta: duas formas de reverter um hashHashing e criptoComo um hash não pode ser invertido, revertê-lo significa buscar, e há duas famílias. Pré-computar uma tabela gigante de pares entrada-para-hash e consultar o resumo (o que o CrackStation faz), ou gerar candidatos em tempo real e aplicar hash em cada um até um coincidir (força bruta). Elas trocam armazenamento por processamento em direções opostas.
Por que o salt derrota tabelas pré-computadasHashing e criptoUm salt é um valor aleatório único armazenado com cada hash de senha e misturado antes de aplicar o hash. Ele faz senhas idênticas gerarem hashes diferentes, o que destrói a economia das tabelas pré-computadas: um atacante precisaria de uma tabela separada para cada salt. O salt é a defesa específica que neutraliza serviços de consulta e tabelas rainbow.
KDFs Lentas: bcrypt, scrypt e Argon2Hashing e criptoO salt derrota a pré-computação, mas não um ataque direcionado de tentar e verificar; um hash rápido ainda permite bilhões de candidatos por segundo. Funções de derivação de chave lentas resolvem isso tornando cada tentativa deliberadamente cara e ajustável, cortando a taxa do atacante em muitas ordens de grandeza. É com elas que você deve armazenar senhas.
Espaço de chaves, entropia e tempo de quebraHashing e criptoSe a força bruta pode reverter um hash se resume ao tamanho do espaço de chaves versus a taxa de hash do atacante. O espaço de chaves cresce exponencialmente com comprimento e alfabeto, então alguns caracteres a mais levam um segredo de quebrado em segundos a inviável por milênios. É a aritmética por trás de por que comprimento e aleatoriedade importam mais.
Como escolher um hash de senhaHashing e criptoArmazenar senhas com segurança é um problema resolvido: use um hash de senha dedicado, com sal e lento, não um resumo cru. Este é um guia curto de decisão, do algoritmo a escolher aos parâmetros a definir e aos erros a evitar, alinhado às diretrizes da OWASP e do NIST.

Identidade e tokens (34)

ArtigoTemaResumo
Anatomia de um JSON Web TokenIdentidade e tokensOs três segmentos de um JWT, como a assinatura garante a confiança no token e por que decodificar um token não é a mesma coisa que verificá-lo.
JWKS e rotação de chaves: como os provedores publicam suas chavesIdentidade e tokensUm JWKS é a lista pública de chaves de assinatura que um provedor de identidade publica para que qualquer um possa verificar seus tokens. Entender o array keys, o kid que nomeia cada chave e por que um provedor mantém mais de uma chave ao mesmo tempo é a base da verificação de tokens.
OpenID Connect: uma camada de identidade sobre o OAuth 2.0Identidade e tokensO que o OpenID Connect adiciona ao OAuth 2.0, o ID token no centro de tudo, os papéis de relying party e provedor, como o fluxo de código de autorização entrega um ID token, e por que um ID token é apenas um JWT que você pode decodificar e ler.
Algoritmos de assinatura de JWT: HMAC, RSA e ECDSAIdentidade e tokensPor que o cabeçalho alg de um JWT importa, a diferença entre assinatura simétrica e assimétrica, e como escolher.
As claims do ID token, e o que uma relying party verificaIdentidade e tokensAs claims dentro de um ID token OIDC: as obrigatórias iss, sub, aud, exp e iat; o nonce que impede repetição; azp quando há múltiplas audiências; acr e amr para a força da autenticação; auth_time; e as claims de vínculo at_hash e c_hash, com a validação que uma relying party realiza em cada uma.
Tipos de chave JWK: RSA, EC, OKP e octIdentidade e tokensToda JSON Web Key declara um kty, e esse único campo decide quais parâmetros a chave carrega. Quatro tipos cobrem quase tudo o que você encontrará: RSA, curva elíptica, as curvas de Edwards e Montgomery, e a sequência de octetos simétrica. A divisão crucial em todos eles é público versus privado.
Armadilhas de segurança em JWT: alg:none, confusão de chave e verificações ausentesIdentidade e tokensO punhado de erros que transforma um verificador de JWT em uma máquina de falsificação, e a validação que um verificador correto deve fazer.
Como verificar um JWT com um JWKS: do kid à assinaturaIdentidade e tokensVerificar um token assinado é uma sequência curta e rigorosa: ler o header, achar no JWKS do provedor a chave cujo kid bate, confirmar o algoritmo e checar a assinatura. Cada passo tem uma armadilha clássica, e é abrindo mão desse rigor que acontecem os bypasses de verificação.
OIDC vs OAuth 2.0: autenticação vs autorizaçãoIdentidade e tokensPor que o OAuth 2.0 é sobre autorização e o OpenID Connect é sobre autenticação, a diferença entre um access token e um ID token, por que usar OAuth puro como mecanismo de login é um antipadrão conhecido, e como saber qual token é qual.
OIDC Discovery: o documento openid-configurationIdentidade e tokensComo o documento .well-known/openid-configuration permite a uma relying party descobrir automaticamente os endpoints e capacidades de um provedor, o que significam os campos issuer, jwks_uri e de algoritmo de assinatura, por que anunciar o algoritmo none é perigoso, e por que o suporte a PKCE S256 importa.
Parâmetros e thumbprints de JWKIdentidade e tokensUma JWK é um objeto JSON que descreve uma chave, e seus parâmetros dizem para que a chave serve e como identificá-la. Além do material da chave, kid a nomeia e um thumbprint (RFC 7638) dá a ela um identificador estável e computado. Este artigo cobre os parâmetros comuns e como um thumbprint é derivado e usado.
Tokens de acesso, tokens de atualização e tokens de IDIdentidade e tokensTrês tokens do OAuth e do OpenID Connect que vivem sendo confundidos, para que cada um de fato serve, e por que enviar o errado ao lugar errado é um bug de verdade.
Ataques de confusão de algoritmo em JWTIdentidade e tokensDuas falhas clássicas de verificação de JWT vêm de confiar no algoritmo declarado pelo próprio token: aceitar alg none, e ser enganado a verificar um token RS256 como HS256 usando a chave pública como segredo. Ambas são derrotadas fixando o algoritmo esperado no servidor em vez de lê-lo do token.
Clientes públicos vs confidenciais, e onde o PKCE se encaixaIdentidade e tokensSe um cliente OAuth consegue guardar um segredo decide todo o seu modelo de segurança. Por que SPAs e apps móveis são clientes públicos, e por que o PKCE agora é recomendado para todos eles.
O fluxo authorization code do OIDCIdentidade e tokensO fluxo authorization code é a forma recomendada de um app obter um ID token: o usuário é redirecionado ao provedor de identidade para logar, o app recebe um código de curta duração, e o troca em um token endpoint de back-channel pelos tokens. Manter o token fora do navegador é o objetivo inteiro.
O fluxo de código de autorização do OAuth 2.0Identidade e tokensOs quatro papéis, a dança de redirecionar e trocar, e por que o código é trocado por um token no canal de fundo.
PKCE: como proteger o fluxo de código de autorização do OAuthIdentidade e tokensO ataque de interceptação que o PKCE derrota, como o verificador e o desafio se encaixam, e por que o S256 é obrigatório.
OpenID Connect: identidade sobre o OAuth 2.0Identidade e tokensComo o OIDC adiciona autenticação à autorização do OAuth, o que é o token de ID e por que o fluxo de código com PKCE é o caminho recomendado.
Como funcionam as senhas de uso único TOTP e HOTPIdentidade e tokensAmbas transformam um segredo compartilhado em um código curto que prova posse sem transmitir o segredo. O HOTP conta eventos; o TOTP conta tempo. O motor por baixo é o mesmo HMAC mais uma etapa de truncamento.
Como validar senhas de uso único: desvio, janelas e repetiçãoIdentidade e tokensGerar um código é a metade fácil. Aceitar um exige tolerar o desvio de relógio, limitar a janela, rejeitar a reutilização e conter as tentativas, cada um um compromisso entre usabilidade e segurança.
Como provisionar autenticadores: URIs otpauth e QR codesIdentidade e tokensAntes de um app autenticador poder gerar códigos, ele precisa do segredo compartilhado e dos parâmetros que o acompanham. Isso é carregado em uma URI otpauth, normalmente mostrada como um QR code para escanear. Conhecer os campos da URI explica o que o QR code de fato contém e por que o segredo está em base32.
Fundamentos de LDAP: o modelo de diretório por trás dos sistemas de identidadeIdentidade e tokensO Lightweight Directory Access Protocol a partir dos princípios: a árvore de entradas e seus distinguished names, a operação de bind que autentica, buscas com base, escopo e filtro, os grupos sobre os quais decisões de acesso se apoiam, e o transporte LDAPS - o vocabulário de trabalho que todo produto de identidade presume antes de a própria documentação fazer sentido.
Kerberos e SPNEGO: como o SSO silencioso de desktop realmente funcionaIdentidade e tokensA maquinaria de tickets por trás do login sem prompt: os dois serviços do KDC, o TGT e o service ticket, por que SPNs e keytabs existem, como o SPNEGO carrega um ticket Kerberos dentro de um cabeçalho HTTP Negotiate, e a pequena lista de coisas - relógio fora de sincronia, SPN faltando, confiança do navegador - que quebram tudo na prática.
SCIM: o padrão que provisiona as contas que o SSO autenticaIdentidade e tokensO System for Cross-domain Identity Management de uma sentada: por que o provisionamento precisava de um padrão, os esquemas de Users e Groups da RFC 7643, o protocolo REST da RFC 7644 - criar, filtrar, PATCH, desativar - e onde o SCIM se encaixa ao lado de SAML e OIDC numa arquitetura de identidade: eles autenticam a conta; o SCIM é como a conta chegou lá.
O modelo de políticas do PingAccess: gateway, agente e a pilha de regrasIdentidade e tokensComo o PingAccess decide quem alcança o quê: as duas formas de implantação (gateway roteando para sites, agentes falando PAAP com um servidor de políticas), a partição em aplicações e recursos, regras compostas em conjuntos e grupos de conjuntos, a ordem fixa de avaliação, e a mediação de tokens que mantém backends legados no jogo.
A plataforma PingDirectory: armazenar, agregar, sincronizar, delegarIdentidade e tokensA plataforma de dados de identidade em quatro peças: o servidor PingDirectory como armazém LDAP de alta performance com REST SCIM 2.0 nativo, o PingDirectoryProxy como gateway LDAPv3 e diretório virtual, o PingDataSync como motor de sincronização bidirecional em tempo real entre armazéns heterogêneos, e o Delegated Admin como superfície controlada de autosserviço - mais a gramática operacional de cn=config, grupos de servidores e movimentos sem downtime.
PingOne: a plataforma atrás dos nomes de produtoIdentidade e tokensO que o PingOne de fato é - uma plataforma multi-tenant de identidade como serviço organizada em ambientes dentro de uma organização - e como seus serviços nomeados (SSO, MFA, Protect, Verify, Authorize, DaVinci) dividem o trabalho, como ela se relaciona com a pilha autogerenciada PingFederate/PingAccess/PingDirectory e com o Advanced Identity Cloud, e por que a mesma palavra aparece em tantos nomes de produto.
PingOne DaVinci: orquestração de identidade como uma telaIdentidade e tokensO que é orquestração de identidade e por que virou categoria própria de produto: os fluxos de arrastar e soltar do DaVinci, o catálogo de conectores que transforma fornecedores em nós, a orquestração dirigida pelo servidor que deixa jornadas mudarem sem release de app, a origem na Singular Key, e como o DaVinci coexiste com as jornadas e árvores de herança ForgeRock sob uma família única de SDKs.
De Sun a Ping: a linhagem ForgeRock decodificadaIdentidade e tokensPor que o catálogo Ping tem dois de tudo: a árvore genealógica do OpenSSO, OpenDS e OpenIDM da Sun, passando por OpenAM, OpenDJ, OpenIDM e OpenIG da ForgeRock, até os atuais PingAM, PingDS, PingIDM, PingGateway e PingOne Advanced Identity Cloud - a fusão de 2023 que criou as pilhas paralelas, qual produto responde por qual nome, e como ler qualquer diagrama de arquitetura Ping sem ambiguidade.
RADIUS de ponta a ponta: um login 802.1X, pacote por pacoteIdentidade e tokensO que um switch e um servidor RADIUS de fato dizem um ao outro quando um notebook é ligado na rede: os campos e códigos de pacote da RFC 2865, os atributos que carregam a identidade e a política, a conversa EAP repassada em atributos EAP-Message, a atribuição de VLAN da RFC 3580, os registros Start e Stop da RFC 2866, o Change of Authorization iniciado pelo servidor da RFC 5176, a cadeia de proxies e as duas coisas que o segredo compartilhado protege e não protege. Cada número vem da RFC em que está.
TACACS+ na administração de equipamentos: um login e um comando, troca a trocaIdentidade e tokensComo um roteador pergunta a um servidor se um engenheiro pode fazer login, se o comando que ele acabou de digitar pode rodar, e como registra que o comando rodou: os três tipos de pacote da RFC 8907, o header de 12 bytes, o START, o REPLY e o CONTINUE da autenticação, a autorização comando a comando com argumentos nome=valor, o START, o STOP e o WATCHDOG do accounting, a ofuscação que a RFC se recusa a chamar de criptografia, o ancestral de 1993 descrito na RFC 1492 e a disciplina da method list, que mantém os equipamentos acessíveis quando os servidores não estão.
802.1X e os métodos EAP: a porta, o envelope e a escolha que define a segurançaIdentidade e tokensControle de acesso à rede baseado em porta, a partir do frame: o supplicant, o authenticator e o servidor, o EAPOL e a porta controlada, os quatro códigos EAP da RFC 3748 e, por fim, a decisão que realmente importa: qual método roda dentro do envelope. EAP-TLS, PEAP, EAP-TTLS, EAP-FAST, TEAP, EAP-pwd, EAP-SIM e EAP-AKA comparados pelo que cada um usa para autenticar, pelo que protege e pelo que exige no cliente, além da única configuração que anula a maioria deles, da atribuição de VLAN que o servidor devolve e das alternativas para os dispositivos que não conseguem fazer nada disso.
NTLM explicado: três mensagens, três versões e por que ele ainda está na sua redeIdentidade e tokensO que o NT LAN Manager de fato é, a partir da especificação da própria Microsoft: um desafio-resposta carregado dentro de outros protocolos, em mensagens NEGOTIATE, CHALLENGE e AUTHENTICATE que começam com a assinatura NTLMSSP; as variantes orientada a conexão e sem conexão; as versões LM, NTLMv1 e NTLMv2 que compartilham um fluxo e diferem na função de resposta; como reconhecê-lo num cabeçalho HTTP; por que sobrevive onde o Kerberos não alcança; o que pass-the-hash e retransmissão significam para ele; e como descobrir o que ainda depende dele antes de desligá-lo.
Autenticação web e portais cativos: a terceira porta para dentro de uma porta autenticadaIdentidade e tokensComo um switch ou uma controladora faz o login de uma pessoa cujo dispositivo não consegue fazer 802.1X: o web authentication proxy do guia de switches da Cisco, a sessão HTTP interceptada e a página de login, a política baixada no sucesso, as páginas de falha e de expiração e a lista de observação, a detecção de hosts por ARP e DHCP snooping, autenticação web local contra central, o limite do HTTPS que está quebrando a interceptação em todo lugar e a substituição do truque pelo IETF, a arquitetura de portal cativo da RFC 8952 e as opções de DHCP e de anúncio de roteador da RFC 8910 que avisam ao dispositivo que um portal existe em vez de forjar respostas.

Identificadores (5)

ArtigoTemaResumo
UUIDs: o v4 aleatório e o v7 ordenado por tempoIdentificadoresComo um identificador de 128 bits continua único sem nenhuma autoridade central, e por que o v7 está virando o padrão para chaves de banco de dados.
Versões de UUID: o que muda da v1 à v8IdentificadoresA família UUID inteira num só lugar: da v1, baseada em tempo e MAC, à v4 aleatória e à v7 ordenada no tempo, mais as versões baseadas em nome e como ler os bits de versão e de variante.
UUIDs vão colidir? Probabilidade e o limite do aniversárioIdentificadoresQuantos bits aleatórios um UUID realmente tem, a matemática do aniversário para uma colisão e quando você quer UUIDs determinísticos.
UUIDs como chaves de banco de dados: v4, v7 e localidade de índiceIdentificadoresO verdadeiro compromisso entre UUIDs e inteiros autoincrementais, e por que chaves v4 aleatórias prejudicam silenciosamente o desempenho do banco.
ULID, KSUID, Snowflake e outros IDs ordenáveisIdentificadoresAs alternativas mais populares ao UUID para identificadores ordenados pelo tempo, como cada uma é montada e por que o UUIDv7 hoje cobre quase tudo aquilo para que elas foram inventadas.

Operações e fieldcraft (20)

ArtigoTemaResumo
Do primeiro sintoma a um chamado que não voltaOperações e fieldcraftCinco passos que nunca nomeiam uma causa raiz. A disciplina é manter separado o que você observou do que você concluiu, porque uma escalação que mistura os dois é uma escalação que volta pedindo a diferença.
Planejar uma mudança, e o passo que todo mundo pulaOperações e fieldcraftMapeie o alcance, escreva o runbook com o plano de retorno, depois compare a saúde antes e depois. O terceiro passo é o que se abandona, e é o único capaz de dizer que a mudança fez o que você prometeu.
Git: o banco endereçado por conteúdo vestindo terno de controle de versãoOperações e fieldcraftO que o Git guarda de verdade (snapshots, não diffs), por que uma branch é só um ponteiro de 41 bytes, como as três áreas explicam quase todo comando confuso, e o que fez de um projeto paralelo de duas semanas o padrão da indústria em quinze anos.
GitHub: o pull request era o produtoOperações e fieldcraftO Git resolveu copiar; o GitHub resolveu coordenar. Como um app Rails de 2008 transformou o patch por e-mail numa conversa revisável, fez do perfil um currículo, acumulou uma plataforma ao redor do repositório e virou o maior host de código do mundo sem nunca ser dono do protocolo por baixo.
O que um engenheiro de sistemas de canal realmente fazOperações e fieldcraftDentro de um distribuidor existe uma função que quase ninguém de fora do canal sabe descrever: o engenheiro de sistemas que atende revendas, não clientes finais. Montagem de lista de materiais em todo projeto que passa por ali, provas de conceito, apresentações, capacitação, bootcamps, feiras. Algumas das revendas atendidas não têm equipe técnica nenhuma, e é esse fato que explica todo o resto do trabalho.
Terminal, shell, TTY, consoleOperações e fieldcraftQuatro palavras usadas de forma intercambiável por quase todo mundo, inclusive pela documentação. Elas nomeiam quatro coisas diferentes, e a distinção explica por que Ctrl+C mata o seu comando mas não o seu shell.
O que é, de fato, um sistema operacional de redeOperações e fieldcraftIOS, Junos, EOS, TMOS, FortiOS, PAN-OS e os demais, comparados nos eixos que importam: sobre o que rodam, como os componentes compartilham estado, onde os planos se dividem, e o que acontece quando uma parte falha.
O caminho que um produto percorre, e os trabalhos ao longo deleOperações e fieldcraftEntre a empresa que constrói uma coisa e a pessoa que depende dela, um produto passa por muitas mãos. Cada par pertence a um trabalho com clientes, fornecedores, responsabilidade e medição próprios — e a medição raramente é a mesma coisa que a responsabilidade.
cron: cinco campos que rodam as tarefas do mundoOperações e fieldcraftTexto e utilitáriosToda máquina Unix carrega um agendador cuja língua inteira são cinco colunas de números e asteriscos. Como lê-los, a regra do OU que pega quase todo mundo, por que 0 e 7 são o mesmo dia, para que as macros @ expandem, e a realidade de horário local por trás de toda execução projetada.
Open source, e os dois sentidos de freeOperações e fieldcraftO inglês sobrecarrega uma palavra pequena, e quarenta anos de história do software pendem dessa ambiguidade. As quatro liberdades, o rebatismo de 1998 que criou o 'open source', copyleft versus permissivas, por que gratuito não é livre — e por que quem fala português nunca teve esse problema.
Decidido de antemão: as cinco práticas que as falhas defendemOperações e fieldcraftDuas páginas companheiras reúnem o que quebrou e o que foi dito. Esta é a terceira pergunta: o que precisa ser decidido antes de qualquer coisa acontecer, porque não pode ser decidido durante. Cinco práticas, cada uma emparelhada com o caso que demonstra o custo de não tê-la - uma linha de base, um raio de dano, uma janela de mudança, um backup restaurável, e uma fronteira.
Como revisar uma arquitetura de rede de forma independente antes de aprová-laOperações e fieldcraftUm projeto chega com um diagrama, uma lista de materiais e uma data. Aprová-lo é uma decisão com anos de consequência, e o material diante de você foi preparado por quem quer a aprovação. Um método para lê-lo nos seus próprios termos: o que pedir antes de começar, as sete perguntas que encontram a maioria dos problemas, como separar o que o projeto diz do que ele presume, e o que uma revisão por escrito deve conter para que a aprovação sobreviva a quem a deu.
Como encontrar as premissas escondidas num diagrama de arquiteturaOperações e fieldcraftRedesUm diagrama mostra o que foi decidido e esconde o que foi presumido. As caixas são produtos, as linhas são intenções, e as coisas que de fato vão falhar, a dependência compartilhada, o pico não medido, a função sem dono, o caminho que só funciona num sentido, não estão desenhadas porque ninguém as pensou como decisões. Oito lugares em que as premissas se escondem num diagrama, as perguntas que trazem cada uma à tona, e o registro que transforma uma leitura em algo que a organização consegue usar no terceiro ano.
O que deve haver numa revisão técnica pós-incidenteOperações e fieldcraftDepois de uma interrupção grave alguém tem de escrever o que aconteceu, e o documento que resulta costuma ser ou uma defesa ou uma acusação. Uma revisão técnica não é nenhuma das duas. É escrita para quem não estava lá, mantém o que foi observado separado do que foi concluído, nomeia as condições que tornaram a falha possível em vez da pessoa que tocou o teclado, e termina em mudanças que podem ser verificadas. O que uma revisão assim contém, quem deve escrevê-la, e os três tipos de revisão que não se podem confundir.
Como separar limitações de produto de falhas de arquiteturaOperações e fieldcraftQuando algo falha, a primeira explicação na mesa é o produto, porque o produto tem um fabricante e o fabricante tem uma linha de suporte. Muitas vezes o produto fez exatamente o que foi construído para fazer, dentro de um projeto que lhe pediu outra coisa. Distinguir os dois importa, porque a correção para uma limitação de produto é um chamado, uma correção ou uma substituição, e a correção para uma falha de arquitetura é uma mudança no projeto, e comprar um produto novo para corrigir um projeto é a forma mais cara de manter o problema. Um método para fazer a distinção, com evidência.
O que executivos devem perguntar antes de aprovar uma transformação de redeOperações e fieldcraftUm programa de transformação chega à mesa executiva como uma visão, um fornecedor, um orçamento e uma data, e o detalhe técnico por baixo dele é exatamente o que as pessoas à mesa foram contratadas para não precisar. Elas não precisam dele. Precisam de doze perguntas cujas respostas dizem se o detalhe foi feito, quem carrega qual risco, o que a organização não vai conseguir desfazer, e quanto os primeiros noventa dias vão custar em atenção. As perguntas, por que cada uma importa, e como soa uma boa resposta.
Modos de arquivo, lidos como o kernel os lê: octal, simbólico e os três bits que quase todo mundo pulaOperações e fieldcraftCodificação e dadosUm modo de arquivo Unix tem doze bits, e quase todo erro de permissão vem de ler nove deles. De onde vem o 755, por que o ls imprime um s ou um T, o que set-user-ID, set-group-ID e a flag de exclusão restrita fazem num arquivo e num diretório, como uma cláusula do chmod sem classe passa em silêncio pelo umask, por que X não é x, e a regra do GNU que preserva o set-group-ID de um diretório quando você digita chmod 755. Do POSIX.1-2024 e do coreutils 9.11, com a calculadora para experimentar cada caso.
Como ler uma mensagem syslog campo a campo: o que o parser verifica e de onde vem cada regraOperações e fieldcraftRedesUma mensagem RFC 5424 tem sete campos de header, um bloco de dados estruturados e um texto livre no final, e cada parte tem uma regra que um parser consegue testar: a regra do zero à esquerda no PRI, o T e o Z maiúsculos do timestamp, o APP-NAME de até 48 caracteres, os escapes dentro dos dados estruturados, o byte order mark que indica UTF-8, os limites de 480 e 2048 octetos e as duas formas de delimitar uma mensagem no TCP. Tudo lido nas próprias RFCs, com o parser aplicando cada regra enquanto você lê.
Níveis de log entre sistemas: uma escala, muitas escadasOperações e fieldcraftRedesO syslog conta para baixo a partir de 0, o Python conta para cima de dez em dez, o Log4j dá a FATAL o menor número e a TRACE o maior, o Windows põe Critical em 1 e o java.util.logging põe SEVERE em 1000. Todo sistema tem uma escada, nenhuma concorda com a outra em direção ou espaçamento, e a mesma palavra cai em lugares diferentes. O SeverityNumber do OpenTelemetry é a única escala escrita para abrigar todas, e este artigo percorre as dez escadas que o mapeador conhece, onde cada degrau cai, e onde o mapeamento é um julgamento e não um fato.
Accounting: quem fez o quê, em qual equipamento e quandoOperações e fieldcraftO terceiro A do AAA tratado como projeto de engenharia, e não como item de checklist: os quatro fluxos de registro que, juntos, respondem à pergunta feita depois de toda queda e de toda invasão (o RADIUS accounting da RFC 2866, o accounting de comandos do TACACS+ da RFC 8907, o syslog da RFC 5424 e o log de mudanças de configuração do próprio equipamento), mais os backups de configuração, que mostram o que os comandos fizeram; o que cada registro contém, campo a campo; os controles da NIST SP 800-53 que dizem o que um registro precisa comprovar; os relógios, a retenção, as chaves de correlação e a segregação de funções que tornam os registros utilizáveis; e o apontamento mais antigo da área: o equipamento em que ninguém configurou para onde enviar esses registros.

Redes (157)

ArtigoTemaResumo
Como funcionam os endereços IPv4RedesSegurança e WAFOperações e fieldcraftTodo header IPv4 carrega dois endereços, origem e destino, cada um deles um número de 32 bits escrito como quatro octetos decimais, com um comprimento de prefixo que o divide em rede e host. Depois da leitura, você consegue converter um endereço para binário e para inteiro à mão, aplicar a máscara como um host faz para decidir se o destino está no próprio enlace, reconhecer os blocos de uso especial e suas regras, e dizer quem distribui os endereços e quando o estoque livre acabou.
Como um ponto de acesso encontra sua controladoraRedesCodificação e dadosOperações e fieldcraftA option 43 do Dynamic Host Configuration Protocol (DHCP) carrega informação específica de fabricante, cujo significado é definido pelo fabricante indicado na option 60; por isso a mesma opção leva endereços binários para um ponto de acesso e texto para outro, enquanto um terceiro lê a controladora na option 138. Depois da leitura, você consegue montar e decodificar byte a byte o valor que cada fabricante documentado espera, fazer o servidor devolvê-lo à classe de fabricante certa, reconhecer a falha silenciosa e o risco do servidor intruso, e ler o valor de volta numa captura ou no servidor DHCP.
O PRI do syslog: um número, dois significadosRedesToda mensagem de syslog começa com um PRI, um número entre colchetes angulares que empacota uma facility e uma severity em um único valor. A fórmula é pequena e a aritmética é fácil depois que você a vê: PRI é igual a facility vezes oito mais severity.
Facilities e severities do syslog, explicadasRedesO syslog define 24 facilities e 8 severities. As severities são uma escala limpa de urgência, de emergency até debug; as facilities são uma mistura de categorias genuinamente úteis e resquícios históricos do Unix, mais oito slots locais nos quais os dispositivos de rede se apoiam bastante.
Fundamentos de subnettingRedesComo dividir uma rede em sub-redes menores e por que todo o segredo está em pegar bits emprestados da parte de host: de onde vieram as sub-redes (RFC 950, 1985), a máscara e a única decisão que o host toma com ela, como achar a sub-rede, o broadcast e a faixa de hosts de qualquer endereço, a velha regra contra a sub-rede zero e por que ela caiu, e os dois prefixos que fogem do padrão de propósito.
Como funciona a notação CIDRRedesO que a barra em 192.168.1.0/24 quer dizer de verdade e como o tamanho do prefixo define um bloco de endereços IP: os três problemas que acabaram com o endereçamento classful (RFC 4632), a notação como o padrão a define, os prefixos mais comuns com a máscara e o tamanho de cada um, os endereços de rede e de broadcast e as duas exceções, por que a agregação era o objetivo e a mesma barra no IPv6.
Syslog em dispositivos de rede: qual facility faz o quêRedesFirewalls, balanceadores de carga e switches quase sempre registram nas facilities locais, mas cada fabricante escolhe um padrão diferente. Saber que o FortiGate usa local7 por padrão, o Cisco ASA usa local4 e o F5 BIG-IP usa local0 transforma uma parede de números de PRI em um mapa de qual caixa disse o quê.
Formatos de mensagem syslog: RFC 3164 vs RFC 5424RedesO PRI é o mesmo em todo lugar, mas o que vem depois não é. O syslog BSD legado (RFC 3164) tem um formato solto e sem ano, enquanto o formato moderno (RFC 5424) é preciso e estruturado. Saber qual você está vendo explica timestamps ausentes, campos ambíguos e por que parsers discordam.
VLSM: como dividir um bloco em sub-redes de tamanhos diferentesRedesOperações e fieldcraftMáscaras de tamanho variável (VLSM) permitem que as subnets recortadas de um mesmo bloco pai tenham prefixos de comprimentos diferentes, cada uma dimensionada para os hosts que precisa abrigar, em vez de uma única máscara para a rede inteira. Depois da leitura, você consegue dimensionar cada subnet pela quantidade de hosts, alocar os blocos do maior para o menor sem que nenhum pule para a frente, dizer quais protocolos de roteamento conseguem carregar o plano e por que o longest match torna as máscaras mistas seguras, contabilizar o espaço livre em blocos alinhados e conferir a alocação no modo VLSM da calculadora CIDR.
Como o syslog viaja: UDP, TCP e TLSRedesO syslog pode trafegar sobre UDP puro, sobre TCP, ou sobre TLS, e a escolha decide se as mensagens podem ser silenciosamente perdidas, reordenadas ou lidas em trânsito. Este artigo cobre os três transportes, as portas envolvidas, e por que qualquer coisa da qual você depende para auditoria não deveria ser enviada sobre UDP.
Uma alocação com VLSM, resolvida do começo ao fimRedesOperações e fieldcraftUm bloco de documentação, 203.0.113.0/24, dividido em cinco subnets de tamanhos diferentes para um site pequeno, com cada endereço de rede, máscara, faixa de hosts e endereço de broadcast escrito e conferido, a sobra contabilizada, os mesmos dois links entre roteadores como prefixos /31, a falha que a ordem de chegada produz e a única rota que alcança o plano inteiro. Depois da leitura, você consegue repetir o procedimento num bloco seu, à mão, com a Calculadora CIDR / de sub-redes e com algumas linhas de Python.
A primeira hora: isolamento de falhas orientado por hipótesesRedesOperações e fieldcraftA diferença entre um incidente de duas horas e um de dois dias costuma ser decidida na primeira hora, e raramente é decidida por ferramentas. É decidida por método: alinhar o início com a mudança, isolar por escopo, ler assinaturas de camada e tratar toda explicação como uma hipótese que a evidência precisa sustentar ou enfraquecer antes que alguém aja sobre ela.
Supernetting e agregação de rotasRedesOperações e fieldcraftO supernetting encurta um prefixo para que uma só rota cubra vários blocos IPv4 alinhados, e a agregação de rotas anuncia essa rota no lugar das mais longas. Depois da leitura, você consegue testar em binário se blocos se fundem, distinguir o agregado exato da super-rede de cobertura e dizer quando esta é legítima, ler como o BGP marca um agregado e por que o AS_SET foi descontinuado em maio de 2025, reconhecer como a agregação falha e conferir tudo na calculadora CIDR, no Python e nos comandos do FRRouting, do Junos e da Cisco.
Janelas de mudança que não viram incidentesRedesOperações e fieldcraftA maior parte das quedas autoinfligidas são mudanças que deram errado sem um caminho limpo de volta. A diferença entre uma mudança e um incidente raramente está na mudança em si; está no runbook em torno dela — o que você verificou antes, como sequenciou, o que o faria parar e se o caminho de volta estava escrito e testado antes de você precisar dele.
Sumarização de rotasRedesOperações e fieldcraftA sumarização de rotas anuncia um único prefixo através de uma fronteira de roteamento no lugar dos muitos que ele cobre, e assim os roteadores do outro lado guardam uma só entrada e não veem os componentes caírem e voltarem. Depois da leitura, você consegue calcular um resumo exato em binário, configurar e conferir faixas de área do OSPF, sumarização externa, sumarização do EIGRP por interface e rotas estáticas sumarizadas, explicar a rota de descarte que impede o loop e reconhecer como uma rota sumarizada esconde falhas e desvia caminhos.
Causa-raiz é um verbo, não um substantivoRedesOperações e fieldcraftA expressão causa-raiz convida a um único vilão e a um final arrumadinho. Incidentes reais raramente têm um; têm fatores contribuintes, e o trabalho honesto é estruturar os candidatos e a evidência que confirmaria ou descartaria cada um — não nomear um culpado antes de a evidência chegar.
Cloudflare: o fosso entregue de graçaRedesA Akamai vendia aceleração e proteção contra DDoS para a Fortune 500; a Cloudflare deu uma versão das duas para qualquer um com um domínio, e fez do próprio plano gratuito o motor — mais tráfego significava peering melhor, peering melhor significava banda mais barata, banda mais barata pagava mais usuários gratuitos. O reverse proxy que cresceu até virar uma rede, um resolver, um computador de borda e uma quantidade desconfortável de poder.
Sobreposições e lacunas de sub-redesRedesOperações e fieldcraftDois prefixos IPv4 se sobrepõem quando algum endereço pertence aos dois, e com prefixos sem classe isso só pode significar que um está inteiro dentro do outro, de propósito ou por engano; lacunas são os endereços de um bloco pai que nenhum prefixo cobre. Depois da leitura, você consegue provar em binário que dois prefixos se aninham ou nunca se tocam, distinguir uma rota mais específica deliberada de um defeito, listar as lacunas de uma alocação como blocos alinhados que fecham a conta de cada endereço e explicar por que túneis e peering na nuvem recusam faixas sobrepostas e como a tradução contorna isso.
Akamai: o teorema que carregou a webRedesUm problema de matemática proposto por Tim Berners-Lee, um algoritmo chamado consistent hashing, e a empresa que transformou os dois na camada invisível sob duas décadas de streaming, lançamentos e notícia quente. O overlay de deploy profundo, o IPO que quase a matou, o cofundador perdido no 11 de Setembro, e a longa reinvenção de cache a segurança a nuvem.
Espaço de endereços IPv4 privados e a RFC 1918RedesSegurança e WAFOperações e fieldcraftA RFC 1918, Best Current Practice 5 desde fevereiro de 1996, reserva 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 para endereços que qualquer organização pode usar internamente: únicos só dentro dela e mantidos fora do roteamento e do DNS da internet. Depois da leitura, você consegue dar os limites e o tamanho exatos de cada bloco, aplicar as regras da RFC 1918 para roteadores de borda e DNS, explicar por que juntar duas redes privadas obriga a renumerar, distinguir uma consulta reversa respondida localmente de uma que vazou para o sumidouro AS112 e conferir cada ponto com ip, dig e Python.
Pensar no raio de impacto antes de mudar qualquer coisaRedesOperações e fieldcraftAntes de uma mudança, a pergunta não é só se isto vai funcionar, mas se der errado, até onde o dano chega. O raio de impacto é o formato desse alcance — alvo, vizinhos, dependentes, pessoas — e pensá-lo em camadas é como você decide o que conter antes de tocar em qualquer coisa.
Chamados de TAC que são triados rápidoRedesOperações e fieldcraftOs chamados de suporte mais lentos raramente são os problemas mais difíceis; são os que foram abertos sem o diagnóstico que o fornecedor precisa. Um chamado que chega completo — problema claro, erro exato, o pacote de diagnóstico, o impacto — pula as idas e vindas e começa com um engenheiro de fato trabalhando nele.
Como funciona o endereçamento IPv6RedesOperações e fieldcraftUm endereço IPv6 é um identificador de 128 bits de uma interface, escrito em hexadecimal com uma única grafia canônica, dividido em prefixo e identificador de interface e classificado pelos primeiros bits. Depois da leitura, você consegue escrever qualquer endereço na forma canônica, dizer o tipo e o escopo dele, dar a um endereço link-local a sua zona, recuperar o endereço de hardware contido num identificador derivado dele e dizer qual registro de DNS reverso liga um endereço a um host.
Como hosts IPv6 obtêm endereços: SLAAC e DHCPv6RedesOperações e fieldcraftUm host IPv6 se configura a partir do que os roteadores anunciam: um endereço link-local que ele testa contra duplicatas, endereços globais que monta por autoconfiguração sem estado a partir de cada prefixo marcado para isso e, onde a rede oferece, endereços, prefixos e servidores DNS concedidos pelo DHCPv6. Depois da leitura, você consegue ler as flags e os tempos de vida de um router advertisement, derivar identificadores de interface EUI-64, estáveis e temporários, distinguir o DHCPv6 com estado, sem estado e de delegação de prefixo, prever qual endereço de origem um host usa, reconhecer anúncios falsos, endereços duplicados e prefixos velhos, e acompanhar cada passo com ip, rdisc6, tcpdump e Wireshark.
Pontos de captura antes dos pacotesRedesOperações e fieldcraftO instinto sob pressão é rodar tcpdump em qualquer lugar conveniente e encarar a enxurrada. O hábito sênior é o oposto: decidir onde observar, em que ordem e o que cada observação significaria - antes de coletar um único pacote. Evidência se projeta, não se pesca.
Sub-redes IPv6 e a fronteira /64RedesOperações e fieldcraftDividir o espaço IPv6 em sub-redes é repartir os 64 bits de cima do endereço entre registro, provedor, site e enlace, porque em quase todo enlace os 64 bits de baixo pertencem ao identificador de interface. Depois da leitura, você consegue explicar por que um enlace é um /64 e o que a autoconfiguração sem estado tem a ver com isso, dimensionar o prefixo de um site e acompanhar a delegação dele, contar e numerar sub-redes em fronteiras de nibble, numerar enlaces entre roteadores e loopbacks com /127 e /128, montar um prefixo local único e evitar os erros que quebram um plano de endereçamento.
Sufixos públicos e o domínio registrado (eTLD+1)RedesCertificados e PKIO que são o sufixo público (eTLD) e o domínio registrado (eTLD+1), por que não dá para calculá-los pegando os dois últimos rótulos do nome, como o algoritmo da Public Suffix List chega à resposta e onde essa fronteira faz diferença: nos limites de emissão de certificados, nos cookies e no same-site.
Descoberta de Vizinhos: como o IPv6 substitui o ARPRedesOperações e fieldcraftO Neighbor Discovery é o protocolo ICMPv6 que todo nó IPv6 executa no seu enlace: cinco mensagens que assumem o papel do ARP, da descoberta de roteadores e dos redirects do ICMP, e cuidam também da detecção de vizinho inalcançável e de endereço duplicado. Depois da leitura, você consegue decifrar as cinco mensagens, calcular à mão um grupo solicited-node e seu endereço Ethernet, acompanhar uma resolução pelo cache de vizinhos, reconhecer anúncios de roteador falsos e o esgotamento de cache com suas defesas e observar tudo com ip, ndisc6, tcpdump e Wireshark.
Mapeie o caminho antes de começar o troubleshootingRedesOperações e fieldcraftAs sessões de troubleshooting mais caras têm um defeito em comum: ninguém sabia de verdade qual era o caminho. O hábito de quem tem experiência é se recusar a raciocinar sobre uma falha antes de modelar a cadeia inteira: com a resolução de nomes incluída, o caminho de volta tratado à parte, cada reescrita e cada fronteira de TLS identificadas, e tudo o que não se sabe marcado claramente como desconhecido.
Baselines antes de você precisar delasRedesOperações e fieldcraftToda comparação é tão honesta quanto o seu lado mais fraco. A disciplina é baseline capturada antes das mudanças, confiança declarada em vez de saúde lembrada, janelas de observação que deixam a convergência falar, alfabetização de churn para os contadores que sempre se movem - e nunca chamar uma mudança de bem-sucedida só por componentes verdes.
Como rodar IPv6 e IPv4 juntos: dual-stack e traduçãoRedesOperações e fieldcraftIPv4 e IPv6 não trocam pacotes entre si, então as redes rodam os dois lado a lado, carregam IPv6 dentro de IPv4 ou traduzem um protocolo no outro. Depois da leitura, você consegue prever qual família um host dual-stack tenta primeiro, montar à mão endereços 6to4, Teredo, 6rd e NAT64, acompanhar passo a passo uma sessão NAT64 com DNS64, explicar por que o 464XLAT traduz em vez de tunelar e reconhecer as falhas que esses mecanismos causam com literais IPv4, respostas DNS assinadas e tamanho de pacote.
O que é um OUI e como os endereços MAC são atribuídosRedesComo é a estrutura de um endereço MAC, o que é o OUI (o prefixo do fabricante) e quem distribui esses prefixos, a diferença entre endereços de administração universal e local, e por que um MAC aleatório de Wi-Fi não tem fabricante nenhum.
Como ler a saída do dig de cima a baixoRedesO dig imprime toda resposta DNS na mesma forma fixa: as linhas de versão e de opções, a linha do header, a linha de flags e contagens, a pseudo-seção OPT, as seções que têm registros e quatro linhas de estatísticas. Depois da leitura, você consegue percorrer qualquer resposta do dig bloco a bloco, dizer o que cada linha informa, reconhecer NODATA, NXDOMAIN, SERVFAIL e uma resposta truncada só pela forma, e escolher as formas mais curtas que um script precisa.
O cabeçalho DNS: opcode, status e flagsRedesOperações e fieldcraftToda mensagem DNS começa com o mesmo header de 12 bytes: um ID de 16 bits, uma palavra de flags que guarda o opcode, sete flags nomeadas, um bit reservado e o código de resposta, e quatro contadores de seção, que o dig imprime como as linhas de header e de flags. Depois da leitura, você consegue decodificar um header a partir dos bytes em hexadecimal, dizer o que cada flag, opcode e status conta para um diagnóstico, reconhecer uma resposta truncada e testar a repetição por TCP que ela exige, e explicar por que o ID e a porta de origem precisam ser imprevisíveis.
Como ler os registros em uma resposta do digRedesCertificados e PKICada registro que o dig imprime é um resource record em cinco colunas: nome do owner, TTL, classe, tipo e os dados específicos do tipo, sem o campo de comprimento que viaja na mensagem. Depois da leitura, você consegue nomear cada coluna, decodificar os dados de registros A, AAAA, CNAME, NS, SOA, MX, TXT, PTR, SRV e CAA, distinguir o TTL decrescente de um cache do TTL da zona, seguir uma cadeia de CNAME até o nome que define o código de status e reconhecer os aliases, timers e erros de aspas que fazem uma resposta aparentemente correta falhar.
O EDNS e a pseudo-seção OPTRedesA pseudo-seção OPT não é um registro, nem algo que você consultou: são metadados do EDNS(0) que o dig mostra perto do topo da resposta. Ela carrega o tamanho de payload UDP, a flag DO, que pede DNSSEC, e opções como COOKIE, e explica, sem alarde, toda uma classe de falhas de resolução.
Registros DNSSEC na saída do digRedesAcrescente +dnssec e a resposta do dig ganha uma nova família de registros: RRSIG, DNSKEY, DS e os registros de negação NSEC ou NSEC3. Aqui você vê o que é cada um, como eles se encadeiam da raiz até uma zona e o que a flag ad garante de verdade.
Como ler a saída do nslookupRedesO nslookup imprime um header Server / Address com o resolver que ele usou, um aviso opcional Non-authoritative answer e, depois, a resposta num formato de texto que muda conforme o tipo de registro. Quem conhece esse formato lê qualquer resultado depressa e vê de relance se a consulta deu certo, de onde veio a resposta e o que ela significa.
nslookup vs dig: qual usarRedesO nslookup e o dig ambos consultam DNS, mas o nslookup é mais enxuto e esconde as flags do cabeçalho e os TTLs que o dig mostra por completo. Este artigo mapeia uma saída sobre a outra e dá uma regra simples para saber qual usar.
Como o nslookup imprime cada tipo de registroRedesEm vez das colunas fixas do dig, o nslookup rotula cada registro em prosa: mail exchanger =, canonical name =, nameserver = e um bloco de várias linhas para o SOA. Um guia curto para ler a linha de cada tipo.
Respostas autoritativas vs não autoritativasRedesUma resposta é autoritativa quando o servidor que a enviou mantém a zona do nome perguntado, e ele diz isso com um único bit do header de DNS, o bit AA, que o nslookup mostra como o marcador Non-authoritative answer e o dig como a flag aa. Depois da leitura, você consegue distinguir uma resposta de cache de um referral, explicar por que uma consulta recursiva é não autoritativa por desenho, perguntar ao servidor da própria zona com a recursão desligada e ler aa na resposta, e dizer o que o bit ainda assim não prova.
Erros do nslookup e o que eles significamRedesQuando uma consulta falha, o nslookup imprime uma linha como ** server can't find NAME: CODE. O código é o diagnóstico inteiro. Este artigo explica NXDOMAIN, SERVFAIL, REFUSED e os timeouts, o que cada um diz e a primeira coisa a verificar em cada caso.
Consultas DNS reversas com o nslookupRedesO DNS reverso mapeia um endereço IP de volta para um nome por meio de registros PTR que ficam sob in-addr.arpa para IPv4 e ip6.arpa para IPv6. O nslookup faz isso automaticamente quando você lhe passa um endereço. Este artigo cobre como o nome reverso especial é construído, por que os servidores de e-mail se importam, e por que o direto e o reverso podem legitimamente discordar.
Modo interativo do nslookupRedesRode o nslookup sem argumentos e ele abre um prompt interativo, em que você pode trocar de resolver, mudar o tipo de registro, ligar a saída de debug e consultar vários nomes na mesma sessão. Os poucos comandos que vale a pena conhecer e quando o modo interativo é melhor do que uma consulta avulsa.
Opções de consulta do dig e como controlar a saídaRedesO poder de verdade do dig está nas opções: escolher a qual servidor perguntar, o tipo de registro e exatamente quanto da resposta mostrar. O artigo cobre as poucas que você vai usar todo dia, do @servidor e do -t ao +short e à combinação +noall +answer, que deixa na saída do dig só os registros.
Como seguir a delegação com dig +traceRedesO dig +trace resolve um nome do jeito que a internet resolve de verdade: começa na raiz, segue a delegação até o TLD e depois até os servidores autoritativos do próprio domínio, mostrando cada hop. É a melhor forma de ver onde a resolução quebra e de entender como as peças do DNS se encaixam.
Anatomia da linha de comando do dig: como o dig interpreta o que você digitaRedesO dig aceita um servidor depois de um @, opções com hífen, um nome, um tipo, uma classe e query options (opções de consulta) com +, em quase qualquer ordem, e usa um valor padrão para tudo o que você deixar de fora. Este artigo percorre a linha da esquerda para a direita: quais palavras valem pela posição e como o dig distingue um nome de um tipo, por que a ordem das opções com + faz diferença e por que duas delas são globais, como o transporte é escolhido (UDP com retry por TCP, TCP para ANY e para transferências de zona, TLS e HTTPS nas suas próprias portas), quais opções mudam bits do header e quais vão no registro OPT do EDNS, o que +trace e +nssearch fazem com a recursão e por que o manual manda guardar o segredo do TSIG num arquivo. Cada afirmação vem do manual do BIND 9 ou de uma RFC, com a fonte citada.
Como as redes herdaram dois alfabetosRedesTexto e utilitáriosCodificação e dadosTodo engenheiro lê letras gregas e algarismos romanos sem nunca ter estudado nenhum dos dois: Ω no terminador, μs no gráfico de latência, λ no plano de comprimentos de onda, Ethernet II em todo analisador de pacotes, um I ou um II gravado no repetidor. Nada disso foi escolhido pensando em redes. Cada símbolo chegou num momento que dá para datar, e são essas datas que contam a história.
Linux: o kernel de hobby que comeu o mundoRedesUm estudante em Helsinque anunciou um projeto que era 'só um hobby, não vai ser grande e profissional como o gnu' — e hoje ele roda os servidores, os celulares, os roteadores, os carros e cada um dos supercomputadores mais rápidos do mundo. Como o kernel foi de fato construído, a decisão de licença que tornou tudo possível, a discussão de arquitetura que ele perdeu no papel e venceu na prática, e as duas brigas que ainda o definem.
As famílias de distribuições Linux: o que de fato as separaRedesToda distribuição entrega mais ou menos o mesmo kernel e mais ou menos as mesmas ferramentas GNU, então as diferenças não estão onde o iniciante procura. Estão no gerenciador de pacotes, no modelo de lançamento, na filosofia de empacotamento e — o mais consequente — em quem decide. Um guia de campo das famílias, descritas pelo que se sente ao administrá-las.
O que nasceu do Linux: celulares, roteadores, contêineres e a pergunta de licença que cada um respondeRedesAndroid, ChromeOS, SteamOS, OpenWrt, as construções Yocto dentro do seu carro e a indústria inteira de contêineres são todos Linux — mas são Linux de maneiras muito diferentes. A parte interessante não é a árvore genealógica. É como cada descendente respondeu à mesma pergunta: quanto precisamos devolver, e como cada um engenheirou a própria resposta?
Como ler um comando curlRedesWeb e HTTPUm comando curl é um comando de shell: a palavra curl, um conjunto de opções e uma URL. Para lê-lo, é preciso ver primeiro como o shell quebra a linha (aspas, barras invertidas, continuações de linha) e depois como o curl lê as flags curtas, longas e agrupadas.
Sinalizadores de dados do curl e a armadilha do Content-TypeRedesWeb e HTTPO curl tem várias formas de anexar um corpo, e elas diferem na codificação e no Content-Type padrão. A grande surpresa é que -d usa codificação de formulário por padrão, não JSON, então um corpo JSON pode ser rotulado errado e recusado.
Como traduzir curl para fetch()RedesWeb e HTTPA API fetch do navegador e o curl descrevem a mesma requisição de formas diferentes. Método, cabeçalhos e corpo se mapeiam de forma limpa, mas algumas diferenças (Content-Type de formulário implícito, cookies e verificação TLS) exigem cuidado.
Cabeçalhos, autenticação e cookies no curlRedesWeb e HTTPCabeçalhos, autenticação e cookies são como uma requisição se identifica e se autoriza. -H adiciona cabeçalhos, -u é HTTP Basic, um token bearer é apenas um cabeçalho, e -b/-c cuidam de cookies. Todos são sensíveis.
Como o curl infere o método HTTPRedesWeb e HTTPO curl nem sempre precisa de -X para escolher um método. Dados no corpo implicam POST, -I implica HEAD, -G força GET, e um -X explícito sempre vence. Conhecer as regras diz num relance o que uma requisição fará.
Sinalizadores do curl que mudam a postura de segurançaRedesWeb e HTTPAlguns sinalizadores do curl mudam o quão segura é uma requisição: -k desativa a verificação TLS, http envia tudo em texto puro, e credenciais na URL podem vazar. Nenhum torna uma requisição maliciosa, mas cada um vale a leitura antes de executar ou compartilhar um comando.
O proxy TCP: o que um middlebox de camada 4 enxerga e o que não enxergaRedesWeb e HTTPUm proxy TCP termina a conexão TCP do cliente e abre outra, separada, até o servidor, emendando dois fluxos independentes na camada 4. Ele reescreve endereços e portas, pode reaproveitar conexões num pool e não enxerga nada do payload da aplicação acima do header de transporte. O artigo explica a diferença entre full proxy e encaminhamento de pacotes, por que o IP de origem desaparece e como o Proxy Protocol o traz de volta.
Proxies HTTP: forward ou reverse, explícito ou transparenteRedesWeb e HTTPUm proxy HTTP faz o parsing das requisições na camada 7 e, por isso, consegue rotear por URL, reescrever headers e aplicar políticas sobre um conteúdo que um proxy TCP não enxerga. Dois eixos descrevem qualquer implantação: forward ou reverse (para qual lado ele trabalha) e explícito ou transparente (se o cliente sabe que ele está ali). O artigo cobre o método CONNECT, os headers X-Forwarded-For e Via, e onde cada combinação é usada.
Os 27 protocolos que o curl falaRedesWeb e HTTPO curl é conhecido como ferramenta de HTTP, mas a versão atual fala 27 esquemas de URL: transferência de arquivos por FTP, SFTP e SMB, e-mail por SMTP, POP3 e IMAP, publish-subscribe MQTT, consultas LDAP e relíquias como Gopher, DICT e Telnet. Conhecer o mapa, e saber quais esquemas começam em texto claro, muda a forma de usar a ferramenta.
HTTP/0.9 vs 1.0 vs 1.1 vs 2 vs 3: cinco versões do protocolo da webRedesWeb e HTTPDe um GET de uma linha, que só buscava HTML, a um protocolo multiplexado rodando sobre QUIC: o que cada versão do HTTP acrescentou, por que ela foi necessária e qual RFC a define hoje, incluindo a reorganização de 2022, que separou a semântica do HTTP (RFC 9110) da sintaxe de transmissão de cada versão.
Os pontos de estrangulamento da internet: um guia de campo do que pode de fato quebrarRedesA internet não tem botão de desligar, mas tem seis lugares onde um número pequeno de pessoas, organizações ou objetos carrega uma fatia enorme das premissas de todo mundo. Nomeação, roteamento, cabo, confiança, concentração e autoridade — o que cada um é, com que velocidade falha, quem conseguiria causar, e o tipo diferente de resposta que cada um admite.
O que acontece se a raiz do DNS sair do ar, ou começar a mentirRedesDesligue as treze identidades de servidor raiz e a internet continua funcionando por uns dois dias; depois, vai se desfazendo um domínio de topo de cada vez, à medida que as delegações em cache expiram. O cenário bem mais perigoso é uma raiz que continua no ar e passa a responder outra coisa, porque o DNSSEC vai assinar fielmente essa nova realidade. A seguir: a linha do tempo real da falha, o que sobrevive, o que dá para fazer hoje e por que todas as raízes alternativas fracassaram.
BGP: o voto de confiança que sustenta a internet inteiraRedesO BGP leva a informação de alcance entre cerca de 74.000 redes independentes e não tem nenhum mecanismo próprio para verificar se um anúncio é autorizado ou se um caminho é real. Depois da leitura, você consegue distinguir um hijack de um route leak como as normas os definem, explicar por que a rota mais específica vence e por que a filtragem do upstream decide o tamanho do estrago, ler os incidentes documentados nos registros de quem os viveu e dos reguladores, e dizer qual defesa (filtragem, origens de rota assinadas, papéis de peering, assinatura de caminho) responde a qual falha.
Cabos submarinos: a internet é, literalmente, um cabo no fundo do marRedesPraticamente todo o tráfego intercontinental passa por algumas centenas de cabos de fibra óptica no fundo do oceano, a maioria com no máximo a grossura de uma mangueira de jardim, e a grande maioria dos rompimentos é causada por equipamentos de pesca e âncoras de navio, não pela ação intencional de alguém. O que acontece de fato quando um cabo se rompe, por que alguns países nem sentem e outros ficam fora do ar, como o reparo funciona na prática e por que redundância no mapa não é redundância no mundo físico.
Validação de origem de rota, feita à mão: Valid, Invalid, NotFoundRedesA validação de origem de rota compara o prefixo e o AS de origem de uma rota BGP com os Validated ROA Payloads que o roteador tem e dá à rota um de três estados. Depois da leitura, você consegue calcular à mão o estado de qualquer rota com os dois testes que a RFC 6811 define, dizer por que uma rota Invalid é Invalid (outro AS, ou um prefixo mais longo que o maxLength), ler AS 0 e maxLength como as RFCs leem e conferir a resposta na calculadora.
Monocultura de nuvem e CDN: o ponto de estrangulamento que ninguém escolheuRedesNinguém decidiu que um erro de configuração numa empresa deveria tirar um quarto da web do ar por uma hora, e ainda assim é mais ou menos esse o arranjo. A concentração em regiões de nuvem, redes de entrega de conteúdo, provedores de DNS e serviços de identidade faz com que organizações sem relação nenhuma falhem no mesmo instante pelo mesmo motivo. Por que aconteceu, o que de fato falha, e por que a resposta óbvia — multinuvem — está quase sempre errada.
Desligamentos de internet: o ponto de estrangulamento que é um telefonemaRedesTodo outro ponto de estrangulamento desta série exige um ataque, um acidente ou um ato de engenharia. Este exige uma instrução a um punhado de empresas que já têm licença. Desligamentos hoje são rotina em algum lugar do mundo quase toda semana — apagões completos, cortes regionais, bloqueio de plataformas, e a opção mais silenciosa do estrangulamento de banda — e o quadro técnico é menos interessante que quem precisa obedecer e quanto isso custa.
AltaVista: feito para quebrar um processador, e perdido ao virar portalRedesO AltaVista começou como benchmark. Um pesquisador queria uma carga caótica o bastante para estressar os novos chips Alpha da DEC, então apontou um rastreador para a web inteira. O resultado liderou a busca por anos e depois foi desmontado pelos próprios donos, o que faz dele o estudo de caso mais claro da indústria sobre perder um mercado que já se tem.
CGNAT: o que quebra quando mil assinantes dividem o mesmo endereçoRedesSegurança e WAFOperações e fieldcraftO carrier-grade NAT (CGN) é um NAT na rede da operadora que divide um endereço IPv4 público entre muitos assinantes, com o shared address space 100.64.0.0/10 numerando o link atrás dele. Depois da leitura, você consegue dizer o que a RFC 6888 exige de um CGN, nomear o que os testes publicados viram quebrar, explicar por que um endereço sozinho já não identifica um assinante, calcular o volume de logging e um port block determinístico, situar o NAT444 entre o DS-Lite e os desenhos A+P e verificar se a sua própria conexão está atrás de um.
Dijkstra: o algoritmo de vinte minutos que os seus roteadores rodam todo diaRedesOperações e fieldcraftEm 1956, Edsger W. Dijkstra criou um algoritmo de caminho mais curto no terraço de um café em Amsterdã, sem lápis e sem papel, para demonstrar um computador novo; todo roteador que roda Open Shortest Path First (OSPF) ou Intermediate System to Intermediate System (IS-IS) calcula a árvore que esse algoritmo produz. Depois da leitura, você consegue contar a história com as palavras dele, executar o algoritmo à mão em seis roteadores, explicar por que o custo de um link precisa ser positivo e por que custos iguais dão vários next hops, e encontrar o resultado e o throttle de SPF num roteador.
Port blocks e port sets: a aritmética de dividir um endereço IPv4RedesOperações e fieldcraftQuando um carrier-grade NAT ou um domínio MAP divide um endereço IPv4 público, o que ele reparte é o campo de porta de 16 bits, em blocos, por uma fórmula determinística ou por campos de bits. Depois da leitura, você consegue calcular quantos assinantes cabem em um endereço e em um pool, quanto o logging por bloco economiza, qual assinante estava com um endereço, uma porta e um horário pela RFC 7422 e quais portas pertencem a um PSID do MAP.
Balanceamento de carga: o que realmente decide para onde vai uma requisiçãoRedesTodo load balancer responde às mesmas quatro perguntas: quais servidores estão vivos, qual deles recebe esta requisição, se este cliente precisa continuar indo para o mesmo lugar e o que acontece quando a resposta muda. Os algoritmos são a parte menos interessante. As quedas vêm do health check, da decisão de persistência e do comportamento no draining.
Segmentação de rede: de domínios de broadcast a identidade, e por que ela falha sempre no mesmo lugarRedesA segmentação começou como correção de desempenho para domínios de colisão, virou controle de segurança por acidente, e hoje é vendida como microssegmentação. Os mecanismos — VLANs, VRFs, VXLAN, zonas de firewall, agentes em host, grupos de segurança de nuvem — cada um resolveu o limite do anterior e herdou um novo modo de falha. A história, os padrões, as arquiteturas, o cenário de fabricantes, e a coisa que derrota toda geração: ninguém sabe o que fala com o quê.
Wi-Fi: um meio compartilhado que se faz passar por cabo, e tudo o que vem dissoRedesA Ethernet resolveu a disputa pelo meio dando a cada dispositivo um fio só dele. O Wi-Fi não tem como fazer isso, então usa o protocolo de rádio dos anos 1970 que a Ethernet abandonou, e desde então cada geração tenta recuperar a eficiência que se perde ao compartilhar o meio. Os padrões, o espectro, as arquiteturas, os fabricantes e por que o erro de implantação mais comum é tratar cobertura e capacidade como se fossem o mesmo problema.
GPON: como uma única fibra atende um bairro inteiroRedesUma Gigabit Passive Optical Network (GPON) leva uma única fibra da central, divide a luz com splitters que funcionam como prismas, sem energia elétrica, e compartilha essa fibra entre dezenas de casas. Como a luz é dividida, por que o upstream precisa de uma agenda de transmissão e para onde vai o orçamento de decibéis.
Bridges e switches: a mesma ideia, resolvida duas vezesRedesA bridge e o switch são a mesma ideia, com poucos anos de distância, e a história passa por duas pessoas que raramente são citadas juntas. Radia Perlman resolveu o problema dos loops na Digital numa única noite, em meados dos anos 1980, e escreveu a resposta na forma de um poema de doze linhas. A Kalpana colocou a mesma função em silício, em cada porta, em 1990, e vendeu o resultado para a Cisco quatro anos depois. No caminho: por que Perlman diz que tudo isso nasceu de um erro da indústria, por que o switch substituiu o hub sem que ninguém chamasse isso de ganho de segurança e o que acontece com uma camada que já foi dada como encerrada várias vezes.
Jumbo frames: quando 1500 bytes não bastam maisRedesPor que a Ethernet ficou nos 1500 bytes, o que os jumbo frames de 9000 bytes realmente trazem de ganho, onde eles fazem diferença e como um MTU mismatch vira um black hole silencioso.
Bits, bytes e os dois significados de quilo: por que um arquivo de 56k leva oito segundos num modem de 56kRedesA conta em que toda conversa sobre redes se apoia e que quase todo mundo erra por pouco: um byte tem oito bits, velocidade de link se mede em bits e tamanho de arquivo em bytes, e quilo quer dizer 1000 em todo lugar, menos onde quer dizer 1024; em 1998, o IEC deu prefixos próprios ao quilo de 1024. Por que um disco de 1 TB aparece como 931 sem faltar nada, por que um link de 100 Mbit/s entrega no máximo 11,87 MB/s de payload TCP (pela RFC 2544 e pelo tamanho mínimo dos headers) e o exemplo resolvido que uma calculadora do site deste autor já trazia em 2004. Com o NIST, a página do ls do GNU, as recomendações ITU-T V.90 e G.704, o IEEE 802.3-2022 e as RFCs.
HTTP QUERY: a leitura que finalmente carrega um corpoRedesWeb e HTTPA RFC 10008 (junho de 2026) deu ao HTTP seu primeiro método novo desde 2010: o QUERY é seguro, idempotente e cacheável como o GET, mas carrega um corpo de requisição como o POST. O que ele corrige, como funcionam seu cache e sua descoberta, por que 'seguro' não é 'inofensivo' e o que cada camada da infraestrutura precisa conferir antes de o tráfego QUERY chegar.
O roteador: de gateway a commodity, e os nomes que ficaram de foraRedesO roteador já foi reinventado pelo menos quatro vezes, e a função dele nunca mudou: ler o destino, escolher o next hop (o próximo salto) e encaminhar. Esta é a história da família: os IMPs de 1969; o primeiro roteador IP de verdade, escrito na BBN por Virginia Strazisar em 1975 e 1976; o roteador multiprotocolo, inventado duas vezes, de forma independente, em 1981, em Stanford e no MIT; a caixa azul que virou a Cisco; e a longa passagem do hardware especializado para o software rodando em máquinas de uso geral. E também por que as duas pessoas que resolveram os problemas mais difíceis do começo das camadas 2 e 3 quase nunca são lembradas.
F5 Distributed Cloud: uma requisição, de ponta a pontaRedesDezesseis artigos sobre o F5 Distributed Cloud, na ordem em que uma requisição passa por eles: como um site entra na malha, onde a requisição chega, que rota ela segue, para onde é encaminhada, como é criptografada, se é permitida, quanto dela é tolerado, o que ela pode chamar, o rastro que deixa e o erro que passa despercebido na configuração que a tratou.
Load balancers e ADCs: construídos contra a estimativa de mercadoRedesNo fim de 1995, um webmaster da Netscape disse a um engenheiro da Cisco que provavelmente havia dez clientes no mundo com um problema de balanceamento de carga. Eles começaram a desenvolver mesmo assim e lançaram o primeiro load balancer do mercado quatro meses depois. Esta é a história da família: o LocalDirector em abril de 1996, o BIG/ip da F5 em julho de 1997, com 200 mil dólares de receita no primeiro ano diante de um concorrente de cinco bilhões de dólares, a troca de nome para application delivery controller e o que acontece com um equipamento cuja função foi absorvida por todas as plataformas que vieram depois.
Extreme Fabric Connect: um serviço, de borda a bordaRedesDez artigos sobre a fabric da Extreme, na ordem em que um serviço passa a existir: qual sistema operacional usar, o que significam os termos, o que é a fabric, como os nós se conhecem, como um serviço atravessa o backbone, por que o multicast não precisa de configuração, como a borda pede o que precisa e como a borda ganha dual-homing sem spanning tree. A ideia que organiza tudo é a mesma sobre a qual a fabric foi construída: o serviço é provisionado na borda, e não levado em trunk de hop em hop.
Como ler uma resposta de DNS: o diagnóstico está na linha que você pulouRedesUma resposta de DNS mostrada pelo dig ou pelo nslookup é a mensagem de resposta inteira: um header com flags e um código de resposta, a pergunta, um pseudorregistro OPT e até três seções de registros, nas quais o endereço é uma linha só. Depois da leitura, você consegue dizer quem respondeu e com que autoridade, ler as flags, a linha OPT, os TTLs e os códigos de falha, perguntar direto ao servidor autoritativo, seguir uma delegação com +trace e achar a parte desta série que aprofunda cada linha.
A indústria, por dentro: seis artigos sobre como este negócio de fato funcionaRedesQuem funda as empresas, como um produto viaja de quem o constrói até quem depende dele, o que o papel no meio desse caminho faz o dia inteiro, o que um cliente está de fato comprando quando compra transformação, e o que todo equipamento do parque está rodando por baixo. Seis artigos que não são sobre fabricante nenhum, lidos na ordem em que uma carreira os encontra.
Transceivers: o artigo que foi ridicularizado e a parte da rede que cabe na mãoRedesEm 1966, um engenheiro de 32 anos, num laboratório britânico, publicou um artigo defendendo que as perdas enormes da fibra óptica vinham de impurezas, e não de um limite da física, e foi amplamente ridicularizado por isso. Quatro anos depois, a Corning provou que ele estava certo, e ele recebeu o Nobel quarenta e três anos depois do artigo. Esta é a história da família dos transceivers: do artigo de Kao ao multi-source agreement, o caso de autocontenção deliberada mais bem-sucedido da indústria, e por que a menor peça substituível de uma rede é a que determina o que essa rede pode vir a ser.
Rede definida por software: um protesto que virou categoria de produtoRedesO trabalho inicial que virou SDN - Ethane, RCP, 4D - nasceu como protesto contra a ossificação das redes. Em sete anos o protesto tinha uma fundação com Cisco e Juniper entre os membros fundadores, e o autor dele tinha vendido a empresa para a VMware por 1,26 bilhão de dólares e virado investidor. Esta é a história da família: o que o movimento de fato pediu, o que a indústria deu em troca, e por que a ideia venceu completamente enquanto o protocolo que lhe deu nome, em boa medida, não.
DNS: um arquivo mantido em horário comercialRedesAntes de 1983, para ter um endereço na rede era preciso ligar para Elizabeth Feinler, no SRI, que incluía você num arquivo que a equipe atualizava umas duas vezes por semana, em horário comercial, exceto nos feriados, e que cada host depois buscava. Jon Postel passou o problema para um aluno de pós-graduação, que leu as propostas que já existiam, escreveu a sua própria e assinou sozinho a especificação do sistema que hoje resolve trilhões de consultas por dia. Esta é a história da família do DNS: o arquivo, o projeto, a segurança que ficou de fora e como um sistema de nomes virou o ponto de controle mais conveniente da internet.
Virtualização: resolvida em 1967, esquecida, depois provada impossível, e feita assim mesmoRedesA IBM colocou um hypervisor funcionando em uso de produção em janeiro de 1967. A indústria então passou quinze anos sem um, porque hardware pessoal barato removeu a razão para compartilhar máquina - e quando a razão voltou, uma análise formal dizia que o processador dominante não podia ser virtualizado. Um grupo de Stanford fez assim mesmo. Esta é a história da família de máquinas virtuais e contêineres: duas linhagens separadas, uma vinda do mainframe e outra de um comando Unix que nunca foi feito para segurança, encontrando-se na infraestrutura sobre a qual tudo hoje roda.
Wireless: o problema das ilhas e o protocolo que virou domínio públicoRedesEm 1968, um professor no Havaí precisava ligar computadores espalhados por quatro ilhas e não tinha como passar cabo pelo Pacífico. A solução foi deixar cada estação transmitir sempre que tivesse algo a enviar e lidar com as colisões quando acontecessem. Essa solução entrou em operação em junho de 1971, foi colocada em domínio público porque não havia um escritório para comercializá-la e hoje está na base do Wi-Fi, das redes móveis, do cabo e da Ethernet. Esta é a história da família, incluindo a decisão regulatória que pesou mais que qualquer protocolo e a falha de criptografia que deu à indústria a sua lição mais cara.
Obsolescência: o que morre de verdade, o que se recusa a morrer e como saber a diferençaRedesA nossa indústria erra sobre obsolescência nas duas direções. Dá como encerradas coisas que sobrevivem décadas a esse anúncio e trata como permanentes coisas que somem num único ciclo de produto. Com base nas histórias de família e nos registros de empresas deste catálogo, este artigo tenta algo mais útil do que prever: os mecanismos concretos pelos quais uma tecnologia realmente morre, as razões concretas pelas quais outras não morrem de jeito nenhum e o que as duas coisas significam para quem está decidindo o que vale a pena aprender.
Observabilidade: o protocolo temporário que sobreviveu ao próprio substitutoRedesEm 1988, um grupo de trabalho publicou um protocolo que fora instruído a manter simples, pensado como paliativo, autenticado por uma senha enviada em texto claro. Ele virou o jeito como o mundo observa suas redes e continua rodando. O sucessor mais seguro dele desabou sob a complexidade da própria segurança. Esta é a história da família - do SGMP e da RFC 1067 até o fracasso da versão 2 e a telemetria por fluxo - e o que ela diz sobre por que segurança ruim sobrevive.
Tempo: a dependência que ninguém listaRedesUm mesmo homem projetou o primeiro roteador moderno em software e o protocolo que mantém os relógios da internet, e fragmentos do código escrito para ele em 1985 ainda estão rodando. Tempo não aparece em diagrama de arquitetura nenhum e está embaixo de certificados, tíquetes, registros, códigos de uso único e metade dos controles de segurança deste catálogo. Esta é a história da família do NTP - o Fuzzball, a RFC 958, os segundos bissextos especificados desde o primeiro documento, e o comando de depuração que virou arma.
O modelo OSI na prática: como mapear tráfego real nas sete camadasRedesO modelo Open Systems Interconnection vale menos como decoreba de prova e mais como uma linguagem comum para localizar problemas: endereço MAC é camada 2, endereço IP é camada 3, porta TCP ou UDP é camada 4, e a aplicação fica por cima. Como encaixar o que você vê na rede em cada camada, onde o modelo não bate com o TCP/IP real e por que o troubleshooting anda mais rápido quando todo mundo fala da mesma camada.
LAN, WAN e as palavras que deixaram de significar distânciaRedesA diferença entre rede local e WAN nunca foi, de fato, uma questão de geografia. O que importava era quem era dono do link e quanto custava transportar um byte, e todo protocolo escrito antes de 1995, mais ou menos, traz embutida uma suposição sobre o lado dessa linha em que ia rodar. Esta é a história da família do escopo de rede: por que as categorias foram inventadas, por que as VLANs e os overlays quebraram essas categorias e por que um setor que passou trinta anos insistindo que o perímetro era um lugar hoje usa a palavra local para dizer confiável.
Switch, roteador e firewall: quem faz o quê no caminho do tráfegoRedesTrês tipos de equipamento ocupam a maior parte de qualquer diagrama de rede: o switch encaminha frames dentro de um domínio de camada 2, o roteador leva pacotes de uma rede para outra e o firewall decide o que pode passar. A função e o propósito de cada um, como um application delivery controller se relaciona com os três e como ler um diagrama de rede sem se perder.
ARP e endereços MAC: como o IP descobre o endereço EthernetRedesNuma rede local, todo pacote é entregue pelo endereço MAC, e o ARP é o serviço que descobre qual MAC corresponde a um IP. O mapeamento um para um entre IP e MAC, como ler a saída do ARP para provar que a resolução funcionou, o gratuitous ARP e o MAC masquerading: o truque de failover que muda um endereço de equipamento sem que os switches percebam.
Tabelas de roteamento e o default gateway: como um pacote escolhe o próximo hopRedesOperações e fieldcraftUma tabela de rotas responde à única pergunta que todo host e todo roteador fazem a um pacote: para onde ele vai agora. O host decide entre local e remoto pela máscara e entrega o resto a um default gateway; o roteador poda a tabela até sobrar uma entrada, por basic match e longest match, com a rota default de prefixo zero como entrada de último recurso. Depois da leitura, você consegue executar a decisão de longest match à mão, ler uma tabela Linux ou Windows linha a linha, dizer como um host aprendeu seu default (à mão, por DHCP, por Router Discovery ou por um Router Advertisement IPv6) e reconhecer um default ausente, morto ou falso pelos sintomas.
Teste e medição: a família que confere as outrasRedesToda outra família deste catálogo constrói alguma coisa. Esta existe para descobrir se o que as outras afirmam é verdade - e começou como ferramenta interna de engenharia cujos direitos alguém levou numa aquisição. Esta é a história: o TART numa subsidiária em 1982, o Sniffer vendendo novecentos e trinta e três milhões de dólares, um documento de padronização que abre acusando os fabricantes de fumaça e espelhos, e um analisador gratuito escrito porque uma empresa só tinha dinheiro para um instrumento.
Como ler ip route, netstat e route print, campo a campoRedesA impressão de uma tabela de roteamento é uma só decisão escrita em três dialetos: o iproute2 do Linux imprime pares de palavra-chave e valor, o net-tools e o netstat do BSD imprimem colunas com letras de flag, e o route print do Windows imprime uma tabela com máscara por família de endereços. Depois da leitura, você consegue nomear cada campo das três saídas, achar as rotas default e dizer qual vence, reconhecer as rotas que descartam tráfego ou que nunca são consultadas, e descobrir à mão qual linha um destino usa.
DHCP: o ciclo de vida do lease por trás do endereçamento automáticoRedesCodificação e dadosOperações e fieldcraftUm lease do Dynamic Host Configuration Protocol (DHCP) é um endereço IPv4 emprestado a um host por tempo fixo: concedido em quatro mensagens, estendido em T1 pelo mesmo servidor ou em T2 por qualquer servidor, e devolvido ao expirar. Depois da leitura, você consegue dizer quem envia cada mensagem a quem, calcular T1, T2 e a expiração de um lease real, explicar DHCPNAK, DHCPDECLINE, DHCPRELEASE e DHCPINFORM, prever o que o cliente faz quando o servidor desaparece, e reconhecer um servidor mudo, um endereço 169.254, um servidor rogue e um pool esgotado.
O ciclo de vida da conexão TCP: handshake, encerramento, e por que conexões falhamRedesToda conversa TCP tem três atos: o handshake de SYN que a cria, o fluxo de dados que a justifica, e o FIN ou RST que a encerra. A diferença entre o fechamento educado e o aborto, as possíveis razões de término de uma conexão, e a lista curta de causas quando uma nem chega a se estabelecer - a alfabetização por trás de toda captura que você vai ler.
Fundamentos de VPN: o que túneis protegem, e o que não protegemRedesUma virtual private network embrulha o tráfego num túnel cifrado para que ele cruze redes não confiáveis como se nunca tivesse saído de casa. O racional - privacidade, criptografia e os limites do anonimato -, os usos válidos de enlaces site-to-site ao acesso remoto, e as fronteiras honestas: o que um túnel genuinamente protege, e as promessas que ele não consegue manter.
A última milha: do POTS à conexão sempre ativaRedesA história da conectividade residencial é a história de um trecho teimoso de infraestrutura, a última milha, reinventado quatro vezes: a telefonia fixa tradicional, que levava voz; o truque do ADSL, que fez o mesmo par de cobre levar dados o tempo todo; a segunda vida da rede de TV a cabo com o DOCSIS; e a fibra até a casa. Por que os 256 kbps de 1999 importaram por muito mais que a velocidade, o que a conexão sempre ativa mudou de fato e como uma mesma casa pode acabar atendida, ao mesmo tempo, pelo fantasma do cobre, pelo coaxial, pela fibra e pelo céu.
Pagers e redes de paging: alcançável antes do tempo realRedesAntes do telefone no bolso, havia o bip no cinto: um receptor de rádio unidirecional numa rede de broadcast em simulcast, alimentada - na sua forma clássica - por uma operadora humana que pegava as palavras de quem ligava e as digitava para o ar. Como as redes de paging de fato funcionavam, dos bipes two-tone ao POCSAG e ao FLEX, por que o modelo de retransmissão por operadora significava estranhos lendo a sua vida em voz alta, e por que hospitais mantiveram pagers muito depois de todo mundo seguir em frente.
Constelações LEO: por que a nova internet por satélite é outro animalRedesSatélites geoestacionários resolveram cobertura e perderam latência: estacionados a 35.786 km, a física sozinha cobra meio segundo de ida e volta. Constelações em órbita terrestre baixa invertem o negócio - satélites a poucas centenas de quilômetros, latência nas dezenas de milissegundos, ao preço de precisar de milhares de satélites em movimento, terminais phased-array que os rastreiam, e handoffs constantes. A geometria, a engenharia que ela força, os enlaces laser entre satélites, e as trocas honestas.
LoRa e LPWAN: quilômetros de alcance numa bateria de moedaRedesHá um canto do networking onde os requisitos invertem tudo que a banda larga otimiza: enviar poucos bytes, poucas vezes por hora, por quilômetros de cidade, de uma bateria que precisa durar anos. LPWAN é esse canto; LoRa é seu cidadão mais conhecido - o rádio de chirp spread spectrum da Semtech trocando taxa de bits por orçamentos de enlace espantosos, e o LoRaWAN, a camada de rede da LoRa Alliance, organizando gateways, classes de dispositivo e a etiqueta de duty cycle do espectro compartilhado.
Métodos HTTP: os verbos da webRedesWeb e HTTPGET, HEAD, POST, PUT, DELETE, PATCH, OPTIONS, TRACE, CONNECT - e agora QUERY. O que cada método promete, por que 'safe' e 'idempotente' são as duas propriedades que de fato importam (para caches, retentativas, proxies e crawlers), por que formulários HTML só aprenderam dois verbos, e como ler a alma de uma API pelos métodos que ela aceita.
Códigos de status HTTP: as cinco famíliasRedesWeb e HTTPTrês dígitos, e o primeiro faz a maior parte do trabalho: 1xx continua, 2xx tem sucesso, 3xx redireciona, 4xx culpa o cliente, 5xx confessa pelo servidor. A lógica das famílias, os códigos que um operador de fato encontra (200, 204, 301 vs 302 vs 307, a dança de cache do 304, 401 vs 403, 404 vs 410, 429, 500 vs 502 vs 503 vs 504), as curiosidades famosas, e por que o primeiro dígito de um código desconhecido sempre basta para agir.
Headers HTTP: a anatomia dos metadadosRedesWeb e HTTPSegurança e WAFTudo o que o HTTP sabe sobre uma mensagem, e que não é a própria mensagem, viaja nos headers: linhas nome, dois-pontos, valor, com nomes que não diferenciam maiúsculas de minúsculas, organizadas em quatro papéis práticos: contexto da requisição, contexto da resposta, metadados da representação e, por fim, negociação e condicionais. A divisão entre end-to-end e hop-by-hop, que rege a vida dos proxies, o header Host, que tornou possível a hospedagem virtual, a negociação de conteúdo, as requisições condicionais e por que a ordem dos headers virou um fingerprint.
Cookies HTTP: estado sobre um protocolo sem estadoRedesWeb e HTTPSegurança e WAFO HTTP esquece você depois de cada requisição - por projeto. Cookies são o retrofit que o deixa lembrar mesmo assim: o servidor escreve um bilhete com Set-Cookie, o navegador o devolve com Cookie, e todo o resto - escopo, vida útil, segurança - são regras sobre quando esse bilhete viaja. Escopo por Domain e Path, vidas de sessão vs persistente, por que o servidor nunca vê o que o navegador sabe, e onde o artigo de flags de segurança assume.
AJAX, XHR e fetch: quando as páginas aprenderam a responderRedesWeb e HTTPNa primeira década, a web tinha um movimento só: clique, tela em branco, página nova. O XMLHttpRequest deu às páginas um segundo - pedir dados em segundo plano, atualizar no lugar - e 'AJAX' batizou a revolução (que prontamente trocou o X pelo JSON). Como o XHR funcionava, o que o fetch consertou (promises, streams, uma API sã), o que ficou igual por baixo (continua tudo HTTP), e a fronteira a que toda requisição de fundo responde: same-origin, com CORS como exceção negociada.
HTML, CSS e o DOM: a página como árvore vivaRedesSegurança e WAFTrês tecnologias, uma divisão de trabalho: HTML declara estrutura, CSS declara apresentação, e o DOM é o que de fato existe em tempo de execução - a árvore que o navegador construiu do seu HTML, a única coisa que scripts tocam, e a razão de 'ver código-fonte' e 'inspecionar elemento' mostrarem mundos diferentes. Como marcação vira árvore, como seletores a endereçam (os mesmos seletores com que o CSS estiliza e os scripts consultam), e por que o DOM é onde o XSS acontece e onde a CSP monta guarda.
O que é um algoritmo? Um primer de trabalhoRedesWeb e HTTPHashing e criptoUm algoritmo é uma receita finita e sem ambiguidade que transforma entrada em saída - e as perguntas de engenharia são sempre as mesmas três: está correto, como o custo cresce, e o que ele troca. Big-O como a gramática do crescimento, por que constantes e assíntotas importam, as famílias centrais que você já opera (busca, ordenação, hash, grafos, máquinas de estado), e onde cada uma já roda dentro das ferramentas deste site.
A família IEEE 802, grupo a grupoRedesO 802 não é um padrão só: é um comitê com vários grupos de trabalho, e cada um cuida de uma parte das duas camadas de baixo. Aqui está o mapa: quem cuida do Ethernet, quem cuida do Wi-Fi, o que querem dizer os números depois do ponto e quais grupos estão ativos, em hibernação ou extintos há muito tempo.
Cabeamento estruturado: o sistema por trás do ponto de redeRedesA TIA-568 transforma a fiação de um prédio, antes improvisada, num sistema: cabeamento horizontal, salas de telecom, o canal de 100 metros, categorias, pinagens e as classificações de resistência ao fogo que a fiscalização realmente confere. O mapa completo, do espelho na parede até o backbone.
BGP: como a internet decide para onde o tráfego vaiRedesO Border Gateway Protocol é o protocolo de roteamento entre sistemas autônomos: cada rede conta aos vizinhos quais prefixes alcança e por quais redes, e cada roteador guarda um best path por prefix, escolhido primeiro pela política local e depois por uma ordem fixa de desempate. Depois da leitura, você consegue situar um número de AS no seu registro, acompanhar uma session do TCP até Established, ler os path attributes, percorrer a escolha do best path numa saída real de roteador e dizer o que um AS path prova e o que não prova.
OSPF: o mapa, a matemática e a área 0RedesOperações e fieldcraftO OSPF é o protocolo de gateway interior link-state padronizado como Internet Standard: cada roteador faz o flooding da descrição dos próprios enlaces, todos os roteadores de uma área guardam o mesmo banco de dados e cada um calcula a própria árvore de caminhos mais curtos a partir dele. Depois da leitura, você consegue calcular uma rota à mão a partir dos costs, dizer por que dois roteadores não viram neighbors, explicar a eleição do designated router e as regras das áreas, definir costs sem cair na armadilha da reference bandwidth e ler a saída de neighbors, banco de dados, rotas e interfaces do FRRouting.
IS-IS: o protocolo de roteamento escondido sob a internetRedesOperações e fieldcraftO Intermediate System to Intermediate System (IS-IS) é o protocolo de roteamento link-state que a ISO escreveu para o OSI e que a RFC 1195 estendeu ao IP: inunda o estado dos enlaces como o OSPF, mas seus pacotes viajam direto na camada de enlace, fora do IP. Depois da leitura, você consegue montar um NET a partir de um endereço de loopback, distinguir o roteamento Level 1 do Level 2, prever qual roteador vira o DIS numa LAN, ler show isis neighbor e show isis database no FRRouting e dizer o que a autenticação protege e o que deixa aberto.
MPLS: rótulos, pilhas e o núcleo livre de BGPRedesOperações e fieldcraftO Multiprotocol Label Switching (MPLS) classifica o pacote uma única vez, na borda da rede, e dali em diante os roteadores o encaminham por um label curto, com swap, pop ou push, sem ler de novo o header IP. Depois da leitura, você consegue decodificar em hexadecimal uma entrada da pilha de labels, nomear os labels de uso especial, seguir um label-switched path numa tabela de bindings real do Label Distribution Protocol (LDP), dizer exatamente o que um núcleo livre de BGP mantém e descarta, e explicar os dois labels de um pacote de rede privada virtual (VPN) de camada 3.
Peer-to-peer, do Napster ao swarm: as arquiteturas que sobreviveram à piratariaRedesNapster, Gnutella, Kazaa, eMule, BitTorrent: em quatro anos, o compartilhamento de arquivos produziu cinco arquiteturas de rede diferentes, cada uma corrigindo a fraqueza que matou a anterior. O índice centralizado, o flooding não estruturado, o supernode, a tabela hash distribuída e o swarm: o que cada um era de verdade, como os tribunais moldaram a topologia e por que essas ideias continuam, sem alarde, por trás do Skype, das CDNs de streaming e das blockchains.
A reserva de mercado brasileira, na teoria e na práticaRedesPor oito anos o Brasil reservou legalmente seu mercado de informática a empresas de capital nacional. A teoria era uma indústria nascente que cresceria e competiria. A prática foi clones, contrabando, uma guerra comercial com Washington e uma geração de engenheiros que aprendeu nas máquinas que a política criou. As duas metades são verdadeiras.
Transformação digital: o que mudou de fato, e como ler o que vem a seguirRedesOperações e fieldcraftTransformação não é a tecnologia chegando. É o momento em que uma capacidade deixa de ser notável e passa a ser pressuposta. Um olhar sobre o que realmente mudou em dinheiro, trabalho, saúde e Estado, e depois um método honesto para ler previsões, incluindo um prazo que é real e está em movimento ao mesmo tempo.
Como a internet é desligada, e quem de fato consegue fazer issoRedesNão existe um interruptor, mas existem pontos de estrangulamento: cabos, roteamento, trocas de tráfego e o pequeno número de empresas por onde a maior parte do tráfego passa. Um passeio pelos mecanismos, pelo que cada Estado realmente consegue fazer com eles, e pela conclusão incômoda de que vigiar tudo é mais fácil do que desligar qualquer coisa.
Quem de fato governa a internet no BrasilRedesO Brasil construiu um dos modelos de governança da internet mais distintos do mundo: multissetorial antes de a palavra existir, com uma fundação de pesquisa operando a primeira conexão do país e um comitê que não é ministério. Os órgãos, as leis, a espinha dorsal de computação estatal por baixo de tudo, e a decisão de 2025 que reescreveu a responsabilidade das plataformas.
A janela das comunicações de dados, 1968 a 1972RedesUm regulador abriu um mercado. A decisão Carterfone permitiu conectar à rede telefônica equipamentos que a AT&T não fabricara, e em quatro anos existia uma indústria de modems e multiplexadores que antes não podia existir. O gatilho, a janela, os produtos que a definiram e por que ela fechou.
Radioamadorismo: indicativos, modos, e por que ainda importaRedesUm indicativo é uma identidade emitida por tratado, legível em qualquer lugar do planeta. O que as letras e o dígito significam, como PY2 diz São Paulo, a diferença entre fonia, CW e digitais, o que uma repetidora de fato faz, e por que um hobby mais antigo que a radiodifusão ainda é o recurso final quando todo o resto falha.
A janela das redes locais, 1979 a 1982RedesAs corporações vinham comprando computadores havia uma década e agora precisavam que eles conversassem dentro do prédio. A janela aberta por volta de 1979 produziu as redes locais e o data PBX, decidiu uma disputa entre duas respostas para o mesmo problema, e fechou quando a resposta ficou óbvia.
O espectro de rádio: até onde vai cada frequência, e por quêRedesPor que um sinal de ondas curtas atravessa um oceano com 100 watts, enquanto o seu Wi-Fi mal passa por uma parede. As faixas de VLF a EHF, os três modos de propagação que explicam quase tudo e o trade-off que define todo o rádio: alcance ou capacidade, nunca os dois.
A janela da interconexão de redes, 1984 a 1988RedesO sucesso da janela anterior criou o problema desta: prédios cheios de redes locais que não se alcançavam. Pontes e roteadores responderam, uma guerra de padrões correu em paralelo, e duas feiras em 1988 tornaram o desfecho visível antes de a discussão terminar formalmente.
As duas feiras de 1988RedesUma feira pôs equipamentos de fabricantes concorrentes numa única rede viva, em público, onde a falha seria vista. A outra mostrou um ecossistema em boa parte descrito, e não entregue. A discussão de padrões seguia formalmente aberta, e quem andasse pelos dois salões não precisava dela encerrada.
Os fundadores que não paravam de fundarRedesLer esta indústria como uma sequência de empresas ignora que ela é, em boa medida, a mesma população de pessoas se recombinando. Ungermann saiu da Intel para a Zilog e da Zilog para a Ungermann-Bass; Metcalfe saiu da Xerox para a 3Com. O que esse padrão explica, e o que não explica.
BFD: quando um enlace está no ar e morto ao mesmo tempoRedesOperações e fieldcraftO Bidirectional Forwarding Detection (BFD) é um pequeno protocolo de hello entre dois planos de encaminhamento que percebe quando um caminho parou de levar pacotes, inclusive quando as duas interfaces continuam no ar, muito antes dos timers do próprio protocolo de roteamento. Depois da leitura, você consegue calcular um tempo de detecção a partir dos dois timers e do multiplicador, ler uma session no FRRouting campo a campo, escolher qual protocolo deve ser o cliente dela e dizer onde o próprio BFD pode ser enganado.
Dimensionar timers do BFD: a aritmética da detecçãoRedesOperações e fieldcraftO Bidirectional Forwarding Detection (BFD) nunca envia o tempo de detecção: cada receptor o calcula a partir do multiplicador do outro lado e do intervalo que os dois acordam, separadamente em cada sentido. Depois da leitura, você consegue partir de uma meta de detecção e chegar a intervalos e a um multiplicador, prever os dois sentidos de uma sessão a partir dos seis números configurados e reconhecer o início lento, o jitter, o hardware e o Echo que esticam o resultado.
Redundância de first hop: VRRP, HSRP e o gateway que é uma ficçãoRedesOperações e fieldcraftOs protocolos de redundância de first hop, como o VRRP e o HSRP, fazem vários roteadores dividirem um único endereço de default gateway e um único MAC virtual, para que os hosts continuem encaminhando tráfego quando o roteador por trás desse endereço cai. Depois da leitura, você consegue dizer o que um host faz e o que não faz sozinho, calcular o tempo de failover do VRRPv3 a partir da prioridade e do intervalo, comparar os defaults do HSRP, reconhecer as falhas comuns e a superfície de ataque e encontrar os dois protocolos numa captura e na saída dos roteadores.
Multicast: o preço de não inundarRedesOperações e fieldcraftO multicast IP envia um datagrama a um endereço de grupo e deixa a rede fazer as cópias, e o preço é estado em cada switch e roteador que precisa saber onde estão os membros. Depois da leitura, você consegue mapear um endereço de grupo para o endereço MAC (media access control), calcular os timeouts do Internet Group Management Protocol (IGMP), explicar por que um switch inunda multicast e o que a falta de um querier provoca, ler o estado do Protocol Independent Multicast (PIM) no FRRouting e dizer o que o Source-Specific Multicast elimina.
Resolvedores DNS públicos: o que você está de fato escolhendoRedesWeb e HTTPOperações e fieldcraftUm resolver público é um resolver recursivo que qualquer pessoa pode usar, e trocar para um deles entrega ao operador todo nome que o seu dispositivo consulta. O que separa 1.1.1.1, 8.8.8.8, 9.9.9.9 e 208.67.222.222 é política, não velocidade: o que é registrado e por quanto tempo, quais endereços filtram e como um bloqueio responde, se há validação DNSSEC, se a sua sub-rede é repassada aos servidores autoritativos e quais transportes cifrados são oferecidos. Depois da leitura, você consegue ler as páginas de um operador contra a lista que a RFC 8932 pede que ele publique, escolher por esses critérios e testar cada um com dig e curl.
Python como calculadora do engenheiro de redes: a biblioteca padrão já sabe a sua aritméticaRedesOperações e fieldcraftHashing e criptoDivisões de sub-rede, agregação de rotas, máscaras wildcard, EUI-64, um cabeçalho DNS em bytes, um HMAC, um p95 de amostras de latência, um tempo de transferência na taxa da linha: cada um é poucas linhas de Python sem instalar nada, porque ipaddress, struct, hmac, statistics e re vêm com o interpretador. Este artigo percorre os doze exemplos com que o playground de Python abre, diz qual módulo faz o trabalho em cada um e por que é o certo, aponta as armadilhas (hosts() em um /31, arredondamento para o par, o bit universal/local), e mostra onde as mesmas respostas saem à mão nas outras ferramentas deste site, para que você confira uma contra a outra.
HTTP a partir da linha de requisição: o que uma mensagem quer dizer e como ela viajaRedesWeb e HTTPToda troca HTTP tem duas mensagens, uma requisição e uma resposta, e desde junho de 2022 o padrão descreve essas mensagens em duas camadas: o que a mensagem significa (métodos, códigos de status, campos de header), definido uma única vez para todas as versões, e como os bytes dela trafegam, definido separadamente para cada versão. É o mapa da série sobre HTTP: qual artigo lê qual parte da mensagem, e em que ordem.
As histórias das famílias: vinte e três tecnologias, cada uma contada desde o primeiro diaRedesVinte e três das tecnologias que formam uma rede e a segurança dela, do transceiver ao firewall de aplicação web, cada uma contada como a história de uma família: o momento, com data, em que ela começou e as pessoas envolvidas, a discussão que decidiu o que ela viria a ser, o que ela mudou nos empregos e nas práticas, e para onde ela vai. Como as histórias são contadas, o que procurar em cada uma e uma ordem de leitura.
O frame Ethernet campo a campo: do preâmbulo ao FCS, a tag 802.1Q e os tamanhos que importamRedesTodo frame Ethernet segue a mesma sequência curta de campos: um preâmbulo que prepara o receptor, dois endereços, um campo que indica um tamanho ou um tipo, o payload e um checksum. O que cada campo leva, por que o mínimo é de 64 octetos e o máximo de 1518, onde fica a tag 802.1Q e o que ela carrega, e por que os jumbo frames não fazem parte do padrão.
VLANs e trunking 802.1Q: tagged, untagged, VLAN nativa e VLAN de vozRedesUma VLAN divide uma rede de switches em várias redes que não escutam os broadcasts umas das outras, e o 802.1Q é o que permite a um único cabo levar muitas delas ao mesmo tempo. Portas de acesso e portas trunk nos termos do próprio padrão, a VLAN nativa e o mismatch que coloca a rede em loop, os ataques de VLAN hopping e as configurações que os impedem, a VLAN de voz por trás de todo telefone IP de mesa e por que o tráfego entre VLANs sempre precisa de um roteador.
Spanning tree em um só artigo: por que a porta bloqueada não é defeito e como o RSTP e o MSTP deixaram o protocolo rápidoRedesLinks redundantes entre switches formam loops, e o header Ethernet não tem nada que impeça um frame de ficar circulando para sempre. O Spanning Tree Protocol resolve isso elegendo um root bridge e bloqueando todas as portas de que a árvore não precisa. O artigo explica a eleição, os custos e os timers, os 30 a 50 segundos que o STP clássico levava para se recuperar, o handshake que deixou o RSTP rápido, as regiões e instâncias do MSTP, as variantes por VLAN da Cisco e seus recursos de proteção, e conta a história da engenheira que escreveu em forma de poema o resumo do artigo em que apresentou o algoritmo.
Link aggregation e LACP: vários links funcionando como um só, e o protocolo que garante que as duas pontas estão de acordoRedesUm link aggregation group (LAG) junta links Ethernet paralelos num único link lógico, para ter mais banda e mais resiliência. O artigo mostra de onde veio o padrão (802.3ad, depois 802.1AX), como o LACP faz as duas pontas entrarem em acordo antes de qualquer frame ser enviado, os timers fast e slow, por que LAGs estáticos são arriscados, por que um fluxo nunca passa da velocidade de um link membro, as regras que os membros precisam seguir, os LAGs entre dois chassis e os modos de bonding do Linux.
Camadas físicas da Ethernet, do 10BASE-T ao 400GBASE: nomenclatura, autonegociação, duplex e o mismatch que arruína um linkRedesA Ethernet é um único formato de frame rodando sobre dezenas de camadas físicas, de 10 Mb/s em cobre de padrão telefônico a 400 Gb/s em fibras paralelas. Como ler um nome como 100GBASE-SR4, as emendas que trouxeram cada velocidade, o que o cobre exige para chegar a 100 metros, como os bits viram sinal, por que o full duplex acabou com as colisões, o que a autonegociação define e como uma ponta fixada em full duplex, com a outra negociando, produz o clássico duplex mismatch.
Fundamentos de fibra óptica: multimodo e monomodo, as categorias e suas cores, conectores e polaridade, o orçamento de perdas e por que a sujeira é a primeira suspeitaRedesA fibra óptica leva os links Ethernet mais longos e mais rápidos. Os dois tipos de fibra e por que um núcleo largo limita o alcance; as categorias OM e OS e as cores de capa que identificam cada uma; até onde um mesmo transceiver chega em cada categoria; os conectores LC, SC e MPO; faces planas e anguladas, e por que uma nunca deve ser conectada à outra; a polaridade, com a transmissão de uma ponta ligada à recepção da outra; o orçamento de perdas calculado com números reais; sujeira, inspeção e limpeza; a luz que não se vê; e as leituras que o próprio transceiver informa sobre si.
Roteamento dinâmico: distance vector, link state e path vector comparadosRedesTodo protocolo de roteamento dinâmico responde à mesma pergunta, para onde mandar o pacote a seguir, e as famílias de protocolos diferem no que cada roteador fica sabendo pelos outros e no que ele calcula por conta própria. No distance vector, os roteadores trocam suas tabelas com os vizinhos; no link state, cada roteador faz o flooding de um mapa da rede e calcula a própria árvore; no path vector, a rota carrega a lista das redes por onde passou; e o DUAL, do EIGRP, aperfeiçoa o distance vector até ele ficar livre de loops a todo instante. O que cada um sabe, como cada um evita loops, com que rapidez cada um se recupera e onde entram o RIP, o OSPF, o IS-IS, o BGP e o EIGRP, com base nas RFCs de cada um.
Redistribuição de rotas e os loops que ela pode criarRedesNa redistribuição, o roteador anuncia num protocolo de roteamento as rotas que aprendeu por outro, ou as próprias rotas estáticas e conectadas. Toda rede com mais de um protocolo precisa dela, e ela é o jeito mais comum de criar um loop de roteamento por configuração. O que o padrão exige, por que a métrica tem de ser inventada na entrada, como a administrative distance transforma dois pontos de redistribuição num loop de feedback e as soluções que funcionam: filtros, tags, redistribuição num sentido só e rota padrão, com base na RFC 1812, nas especificações do OSPF e do RIP e nos exemplos da própria Cisco.
Opções de BOOTP e DHCP: o que o cliente pede, e o que ele recebeRedesNomear cada campo do pacote que o BOOTP definiu em 1985 e que o DHCP envia até hoje, e explicar como o DHCP transformou o último campo numa lista de opções. Decodificar uma opção do magic cookie até o marcador de fim, dizer o que as opções mais comuns carregam e que lado as envia, e usar o registro da IANA para distinguir um código padrão de um código privado quando uma captura ou um log de servidor mostra um número desconhecido.
O relay agent de DHCP: um servidor para muitas sub-redesRedesUm cliente DHCP que ainda não tem endereço faz broadcast da requisição, e o servidor de que ele precisa costuma estar em outra rede. O relay agent recebe esse broadcast, marca nele o endereço da sub-rede de origem, envia uma mensagem nova ao servidor e traz a resposta de volta. Depois da leitura você consegue acompanhar as duas mensagens passo a passo, explicar giaddr, o campo hops, a flag BROADCAST e a opção 82, configurar ip helper-address no Cisco IOS e diagnosticar uma sub-rede remota que não recebe lease.
PXE e boot pela rede: como uma máquina sem disco descobre o que executarRedesUma máquina sem sistema operacional, ou sem disco nenhum, ainda consegue dar boot pedindo à rede um endereço e o nome de um programa para baixar e executar. Depois de ler, você vai conseguir acompanhar um boot PXE do primeiro DHCPDISCOVER até a primeira instrução executada, ler as opções que identificam o cliente, explicar por que o Proxy DHCP escuta na porta 4011, escolher o arquivo de boot certo para máquinas BIOS e UEFI e situar os sucessores do projeto de 1999 em IPv6 e HTTP.
TFTP: a transferência de arquivos mais simples, e onde ela ainda rodaRedesWeb e HTTPO Trivial File Transfer Protocol move um arquivo sobre UDP em blocos de 512 bytes, um bloco em trânsito e um ACK para cada um, sem login e sem listagem de diretório. Depois da leitura, você consegue acompanhar uma transferência pacote a pacote, da porta 69 ao último bloco curto, explicar a Sorcerer's Apprentice Syndrome e as opções que negociam tamanho de bloco, timeout, tamanho de arquivo e janela, e dizer onde o protocolo ainda roda e o que verificar quando uma transferência trava.
Transferências de zona e NOTIFY: como os servidores secundários ficam em diaRedesToda zona DNS precisa ser servida por pelo menos dois servidores autoritativos, e as cópias precisam concordar. Depois da leitura, você vai saber ler os timers do registro SOA de uma zona e prever quando o secondary faz polling, reconhecer uma troca AXFR, IXFR ou NOTIFY numa captura de pacotes, explicar por que as transferências são restringidas e cifradas, e conferir com o dig se os servidores de uma zona têm o mesmo serial.
DNSSEC de ponta a ponta: da chave da raiz à resposta validadaRedesDepois de ler, você consegue acompanhar uma validação DNSSEC desde o trust anchor da raiz até a resposta assinada, nomear o registro que carrega cada elo e explicar por que um resolver devolveu SERVFAIL, uma flag ad ou nada de especial. Também vai saber qual chave da raiz está assinando hoje, quais algoritmos o registro da IANA ainda permite e como conferir uma validação com dig e delv.
DoT, DoH e DoQ comparados: como cifrar a perguntaRedesO DNS clássico manda toda pergunta às claras, e o trecho entre o stub resolver e o resolver recursivo é onde quem escuta aprende mais. DoT, DoH e DoQ cifram esse trecho de três maneiras diferentes. Depois da leitura você consegue dizer o que cada um esconde e o que nenhum deles esconde, ler suas portas e seu enquadramento, distinguir o perfil Strict do Opportunistic, explicar como um cliente descobre um resolver cifrado e escolher um transporte para uma rede com os argumentos dos próprios padrões.
Anycast: um endereço em muitos lugaresRedesO anycast anuncia um mesmo endereço de serviço a partir de muitos lugares independentes e deixa o sistema de roteamento decidir qual deles cada cliente alcança. Depois de ler, você consegue defini-lo nas palavras da RFC 1546 e da BCP 126, explicar por que mais próximo quer dizer mais próximo na tabela de rotas e não no mapa, dizer por que o DNS sobre UDP se encaixa nele e o TCP sofre, ler a lista de servidores raiz do root-servers.org e rodar uma consulta dig que revela qual instância respondeu a você.

Segurança e WAF (126)

ArtigoTemaResumo
Headers de segurança HTTP: a camada de defesa em profundidadeSegurança e WAFO que são os headers de segurança HTTP, por que eles formam uma camada de defesa por cima do código seguro, e não um substituto dele, quais headers têm mais peso e como avaliar num relance a postura de uma resposta.
O fingerprint que quebrou e o que o próprio autor escreveu para substituí-loSegurança e WAFO Chrome passou a embaralhar as extensões TLS em 2023, e o JA3 deixou de identificar o Chrome. A correção veio da mesma pessoa que criou o JA3, e o motivo de ela funcionar cabe numa palavra: ordenado.
Quantificadores e classes de caracteres em regexSegurança e WAFWeb e HTTPUma expressão regular é construída a partir de duas perguntas: qual caractere eu quero e quantos deles? As classes de caracteres respondem à primeira, os quantificadores respondem à segunda. Acerte essas duas e a maior parte das regex se encaixa.
SAML 2.0: como funciona o SSO no navegadorSegurança e WAFIdentidade e tokensO que é uma asserção SAML, os papéis do provedor de identidade e do provedor de serviço, o fluxo de Web Browser SSO (login único, do inglês single sign-on) iniciado pelo SP de ponta a ponta, e a diferença entre os bindings HTTP-POST e HTTP-Redirect que transportam as mensagens.
Content Security Policy, diretiva por diretivaSegurança e WAFComo a CSP funciona como controle contra cross-site scripting e injeção: a forma de uma política, por que default-src importa, o que 'unsafe-inline' e 'unsafe-eval' entregam, como nonces e hashes permitem código inline específico com segurança e para que serve o modo report-only.
Dentro de uma asserção SAML: sujeito, condições e audiênciaSegurança e WAFIdentidade e tokensA anatomia de uma asserção SAML: o Subject e os formatos de NameID, a SubjectConfirmation do tipo bearer e as verificações de NotOnOrAfter / Recipient / InResponseTo, a janela de validade das Conditions, a AudienceRestriction e o AuthnStatement, com a validação que um provedor de serviço deve fazer em cada uma.
Grupos, retrorreferências e lookarounds em regexSegurança e WAFWeb e HTTPOs parênteses fazem muito mais do que definir precedência em uma regex. Eles capturam texto para você reutilizar, nomeiam as partes que importam e — com um prefixo de interrogação — permitem afirmar o que vem antes ou depois sem consumir.
Assinaturas SAML e XML-DSigSegurança e WAFIdentidade e tokensComo uma mensagem SAML é assinada com XML Signature: o ds:Signature envelopado, os algoritmos SignatureMethod e DigestMethod, por que o SHA-1 é fraco, a diferença entre assinar a Response e assinar a Assertion, e como funcionam os ataques de signature wrapping em XML.
Backtracking catastrófico e ReDoSSegurança e WAFWeb e HTTPAlguns padrões de aparência inocente podem levar segundos, minutos ou praticamente uma eternidade em uma string curta. A causa é o backtracking catastrófico, e quando um atacante controla a entrada ele vira uma falha de negação de serviço. Eis por que acontece e como escrever padrões que não podem travar.
HSTS e a exigência de HTTPSSegurança e WAFComo o Strict-Transport-Security fecha a janela de downgrade para HTTP; o que fazem o max-age, o includeSubDomains e o preload; a brecha da confiança no primeiro uso, que o preload elimina; e os erros de configuração que desativam o HSTS sem ninguém perceber.
Uma Content Security Policy, lida como o navegador a lêSegurança e WAFWeb e HTTPUm cabeçalho CSP é uma frase numa pequena linguagem formal, e o navegador o lê com um algoritmo que a especificação soletra: dividir nos pontos e vírgulas, passar os nomes a minúsculas, ignorar uma diretiva que se repete, ler cada token de um valor contra uma gramática. A maioria das políticas quebradas quebra exatamente nesses passos, e em silêncio: uma palavra-chave sem aspas vira nome de host, um ponto e vírgula faltando funde duas diretivas numa só, um default-src que parece protetor não governa nada depois que script-src é definido, 'unsafe-inline' ao lado de um nonce é ignorado sem aviso. Aqui está a leitura do próprio CSP Level 3, passo a passo, com a cadeia de recurso, as regras de casamento para curingas, esquemas e endereços IP, o que 'strict-dynamic' desliga, e a política de três diretivas que a própria especificação chama de Strict CSP.
Âncoras e limites em regexSegurança e WAFWeb e HTTPÂncoras casam uma posição, não um caractere: o início ou o fim da string, ou a borda de uma palavra. São a diferença entre um padrão que casa em qualquer lugar e um que casa só onde você quer. Este artigo cobre ^, $, \b e seu comportamento em modo multilinha, além dos erros que causam.
Flags de segurança de cookiesSegurança e WAFComo Secure, HttpOnly e SameSite protegem os cookies de sessão, o que cada valor de SameSite significa, por que SameSite=None exige Secure e como os prefixos __Host- e __Secure- impõem essas garantias no nível do navegador.
XXE e por que um parser SAML rejeita DOCTYPESegurança e WAFIdentidade e tokensComo funcionam os ataques de Entidade Externa de XML (XXE), a negação de serviço billion laughs, por que ambos dependem de uma DTD, e por que um decodificador SAML reforçado rejeita qualquer DOCTYPE ou declaração de entidade de imediato em vez de tentar interpretá-lo com segurança.
Bindings SAML e iniciação por SP vs IdPSegurança e WAFIdentidade e tokensUm fluxo SAML pode começar no serviço ou no provedor de identidade, e as mensagens podem viajar por dois bindings diferentes: um redirect HTTP com a mensagem compactada na URL, ou um formulário HTML de auto-submit que a envia por POST. Qual binding carrega qual mensagem, e onde o fluxo começa, explica muito do comportamento do SSO.
Clickjacking e controle de enquadramentoSegurança e WAFO que é clickjacking, como o enquadramento o torna possível, a diferença entre o cabeçalho legado X-Frame-Options e a diretiva moderna CSP frame-ancestors, por que ALLOW-FROM é obsoleto e como os dois controles interagem.
Flags e modos em regexSegurança e WAFWeb e HTTPUma flag muda como o padrão inteiro casa: sensibilidade a maiúsculas, se ^ e $ enxergam linhas, se o ponto cruza quebras de linha e se o espaço em branco no padrão é ignorado. O mesmo regex pode casar coisas completamente diferentes dependendo de suas flags, então conhecê-las evita muita confusão.
O SAML proxy: como inserir uma camada de identidade numa sessãoSegurança e WAFIdentidade e tokensUm SAML proxy fica no fluxo de SSO em vez do caminho dos pacotes: ele termina a requisição do usuário, força a autenticação contra um provedor de identidade, e só então deixa a sessão passar, usando o modelo de redirecionamento por navegador do SAML. Ele pode agir como provedor de serviço para o IdP e provedor de identidade para a aplicação ao mesmo tempo (um proxy ou broker), que é como um único login federa muitos sistemas downstream. Este artigo explica os papéis, o fluxo, e por que ele é um proxy afinal.
Como ler OGNL num log de WAF: o que a carga pretendia fazerSegurança e WAFWeb e HTTPCodificação e dadosUma carga OGNL num log tem duas metades que vale distinguir: algo que tenta desligar o sandbox de expressões e algo que tenta executar um comando. Com as duas, é tentativa de exploração. Só com a segunda, normalmente é um scanner percorrendo uma lista. Sem nenhuma das duas, é sondagem verificando se a entrada é avaliada - e essa resposta decide se qualquer outra coisa da lista teria chance.
XXE e entidades externasSegurança e WAFXML permite que um documento declare entidades, e uma entidade externa pode apontar para um arquivo ou URL. Um parser que resolve uma pode ser enganado a ler arquivos locais ou fazer requisições no lado do servidor, a vulnerabilidade XXE. A correção é direta e eficaz: não processar um DOCTYPE de forma alguma.
Billion laughs e expansão de entidadesSegurança e WAFEntidades podem referenciar outras entidades, e se cada uma multiplica a anterior, um documento minúsculo pode expandir para gigabytes e exaurir a memória. O ataque billion laughs transforma isso em uma negação de serviço. A defesa é limitar a expansão ou recusar o DOCTYPE de imediato.
Como funciona a pontuação CVSSSegurança e WAFO CVSS transforma uma string de vetor curta em um número de severidade de 0 a 10 usando uma fórmula fixa. A pontuação Base é construída a partir de duas subpontuações: Explorabilidade (quão acessível e fácil é a falha) e Impacto (quão grave é o resultado). Todo o resto refina essa base. Isso é aritmética, não opinião, e por isso uma calculadora reproduz exatamente qualquer pontuação publicada.
As métricas Base do CVSS, explicadasSegurança e WAFA pontuação Base vem de oito métricas em duas famílias. Quatro métricas de explorabilidade (Vetor de Ataque, Complexidade do Ataque, Privilégios Necessários, Interação do Usuário) descrevem quão difícil é o ataque, e quatro métricas de impacto (Escopo, mais Confidencialidade, Integridade e Disponibilidade) descrevem o dano. O Escopo é a sutil: é o que permite que uma pontuação ultrapasse a fronteira do próprio componente vulnerável.
Pontuações Temporal e Ambiental do CVSSSegurança e WAFA pontuação Base é apenas o ponto de partida. As métricas Temporais a reduzem conforme os fatos surgem, como o lançamento de um patch, e só podem diminuir a pontuação. As métricas Ambientais permitem que uma organização recalcule a falha para seus próprios sistemas, elevando ou reduzindo a importância de confidencialidade, integridade e disponibilidade e sobrescrevendo métricas base. Ambas são opcionais, mas produzem um número mais honesto.
Como ler uma string de vetor CVSSSegurança e WAFUm vetor CVSS é uma string compacta e autodescritiva: um prefixo de versão seguido de pares métrica:valor separados por barras. Aprender a lê-la diretamente, em vez de confiar em uma pontuação renderizada, permite detectar erros de transcrição e entender exatamente o que um fornecedor afirmou. As métricas Base são obrigatórias e o resto é opcional.
Faixas de severidade do CVSS e o que o score não dizSegurança e WAFO número de 0 a 10 corresponde a cinco faixas qualitativas, de Nenhuma a Crítica. Essa divisão ajuda na triagem, mas o score Base do CVSS mede severidade, não risco. Ele não diz nada sobre a falha estar sendo explorada, sobre o valor do ativo ou sobre os controles que você tem. Usar o número Base como fila de prioridade é o jeito mais comum de as equipes usarem mal o CVSS.
CVSS v3.0, v3.1 e v4.0: o que mudouSegurança e WAFEste decodificador calcula CVSS v3.0 e v3.1. As duas versões v3 compartilham uma fórmula mas diferem no arredondamento e em um termo ambiental, então as pontuações podem diferir em um décimo. O CVSS v4.0, lançado em 2023, é um redesenho maior, com novos grupos de métricas e sem a métrica Escopo, e seus vetores não são compatíveis com ferramentas v3. O CVSS v2 está descontinuado.
Fingerprinting TLS passivo: JA3, GREASE, e o churn que levou ao JA4Segurança e WAFUm ClientHello anuncia o cliente às claras, e a combinação de versões, ciphers, e extensões é característica do software que o enviou. Isto cobre como o JA3 transforma isso em um hash, por que o GREASE precisa ser removido, como a randomização da ordem das extensões quebrou o JA3 (o churn), como o JA3N e o JA4 restauram a estabilidade, e onde um fingerprint TLS se encaixa como sinal para secure web gateways e autenticação adaptativa.
O que é server-side request forgery (SSRF)Segurança e WAFSSRF é uma vulnerabilidade em que um atacante faz o servidor emitir uma requisição HTTP para um destino escolhido por ele. Como a requisição parte de dentro da rede do servidor, ela alcança serviços internos, metadados de nuvem e endereços de loopback que o atacante jamais alcançaria diretamente. A correção é validar o destino, não o texto da URL.
Faixas de IP privadas, reservadas e públicasSegurança e WAFRedesWeb e HTTPA IANA registra todos os blocos IPv4 e IPv6 de propósito especial, de loopback, link-local e uso privado ao espaço compartilhado, à documentação e aos prefixos de tradução, e duas colunas desses registros, Destination e Globally Reachable, decidem se um endereço é um destino público. Depois da leitura, você consegue ler essas colunas, classificar um endereço só depois de transformar sua grafia no número ao qual o cliente se conecta, explicar como um destino público ainda leva para dentro por uma segunda consulta DNS ou por um redirecionamento, citar os endereços de metadados de nuvem e testar um filtro de SSRF.
Truques de ofuscação de endereço IPSegurança e WAFUm endereço IP pode ser escrito de muitas formas: decimal simples, octal, hexadecimal, forma abreviada e IPv6 mapeado em IPv4. Cada forma volta a apontar para o mesmo endereço, e é assim que atacantes passam um alvo interno por um filtro que só bloqueia a grafia decimal pontuada. Por isso verificações de SSRF precisam decodificar, não comparar texto.
Endpoints de metadados de nuvem e SSRFSegurança e WAFToda nuvem grande dá a uma instância um serviço de metadados em um endereço link-local fixo, e ele pode devolver credenciais temporárias do papel da instância. Isso o torna o alvo de SSRF de maior valor. Conhecer os endpoints, e as defesas no estilo IMDSv2, é essencial tanto para entender o ataque quanto para a defesa.
Como se defender de SSRF com allow-listsSegurança e WAFA defesa durável contra SSRF é uma allow-list de destinos pretendidos, combinada com resolver o endereço antes de confiar nele e reverificar após redirecionamentos. Block-lists de faixas internas ajudam, mas perdem para ofuscação e DNS rebinding. Esta é a abordagem em camadas que se sustenta.
Esquemas de URL perigosos em SSRFSegurança e WAFSSRF não se limita a http. Esquemas como file, gopher, dict e ftp permitem a um atacante ler arquivos locais ou forjar bytes brutos para serviços internos como Redis e SMTP. Um buscador de URL que não restringe o esquema entrega ao atacante uma primitiva muito mais poderosa do que uma simples requisição web.
SSL forward proxy: como funciona a interceptação de TLS de saída e o que a faz falharSegurança e WAFCertificados e PKITLS e transportePara inspecionar o tráfego de saída criptografado, o forward proxy faz um man-in-the-middle controlado: termina a sessão TLS do usuário, abre a sua própria sessão até o servidor real e forja um certificado para esse servidor, assinado por uma CA privada em que os dispositivos da própria organização confiam. Este artigo explica a mecânica, o modelo de confiança que torna isso seguro (e perigoso) e por que o pinning, o HSTS e o TLS mútuo derrotam a interceptação.
A LGPD para engenheiros: o vocabulário que importaSegurança e WAFA lei brasileira de proteção de dados atribui um papel a você, oferece dez bases legais em vez de uma e coloca um relógio de três dias úteis na comunicação de incidentes. O que controlador, operador e encarregado significam quando é você quem opera os sistemas.
Fingerprinting passivo: o que você emite sem ninguém perguntarSegurança e WAFRedesToda conexão anuncia a sua pilha antes que um único byte de dados da aplicação seja enviado. Como um SYN do TCP, uma string de User-Agent e a simples ordem dos headers HTTP identificam, cada um, um cliente, e por que a contradição entre eles é o sinal clássico de proxy e de bot.
Hacking no século XX: um guia de campo sobre a gente que desmontava as coisasSegurança e WAFDe um menino cego assobiando num telefone nos anos sessenta a sete hackers depondo ao Senado americano sob seus apelidos em 1998 - o arco inteiro, num lugar só. Quem eram essas pessoas, o que de fato fizeram, quais histórias são verdadeiras, e como uma subcultura criminalizada acabou construindo a indústria de segurança que hoje a emprega.
Phreaking: a rede que assobiava as próprias senhasSegurança e WAFAntes de alguém hackear um computador, hackeavam a companhia telefônica - porque a rede de longa distância carregava seus tons de controle no mesmo fio da voz, e um apito de brinquedo de caixa de cereal por acaso cantava a frequência mágica. Joybubbles, o Captain Crunch, o artigo da Esquire que acendeu o pavio, a blue box que dois moleques chamados Steve venderam antes de fundar a Apple, e a lição de arquitetura que a indústria pagou caro para aprender: nunca ponha o plano de controle no plano de dados.
O worm de Morris: a noite em que a internet descobriu que era frágilSegurança e WAFEm 2 de novembro de 1988 um mestrando de Cornell soltou 99 linhas de C para medir o tamanho da internet. Uma única decisão aritmética sobre reinfecção transformou a medição no primeiro desastre em escala de internet, deu à luz o sistema CERT, produziu a primeira condenação sob o novíssimo Computer Fraud and Abuse Act, e ensinou à rede uma lição sobre monocultura e confiança que ela ainda está reaprendendo.
The Cuckoo's Egg: 75 centavos, dez meses e a invenção da resposta a incidentesSegurança e WAFEm 1986 um astrônomo recebeu uma diferença contábil trivial e a ordem de encontrá-la. Ele a seguiu por um laboratório de Berkeley até dentro de redes militares americanas e, do outro lado, até um hacker da Alemanha Ocidental que vendia acesso ao KGB - improvisando, no caminho, o caderno de bordo, a linha do tempo, o honeypot e quase todo reflexo que a profissão hoje ensina.
Kevin Mitnick: o mito, o homem, e o que o caso de fato decidiuSegurança e WAFChamaram-no de hacker mais perigoso do mundo, ficou anos preso sem julgamento e foi proibido de tocar num telefone sem supervisão - com base em alegações que não sobrevivem ao contato com os autos. A história real é menor e muito mais útil: um engenheiro social de habilidade extraordinária, uma narrativa de imprensa que virou acusação, e um caso que moldou como se acusa crime de computador e como se trata pesquisadores até hoje.
Kevin Poulsen: o homem que ganhou um Porsche dominando a companhia telefônicaSegurança e WAFDark Dante tomou todas as linhas de entrada de uma rádio de Los Angeles para garantir que seria o ouvinte 102, e saiu dirigindo um Porsche. Ele também era funcionário de uma empreiteira de defesa durante o dia, o primeiro americano acusado de espionagem por um crime de computador, e - depois de cinco anos de prisão - o editor que revelou algumas das maiores histórias de segurança dos anos 2000 e coconstruiu um sistema de vazamento para jornalistas.
Os 414s e o verão de 1983: o ano em que hackear virou crimeSegurança e WAFSeis adolescentes de Milwaukee com modems entraram sem querer num hospital de câncer, num banco e num laboratório de armas nucleares. WarGames estreou no mesmo verão. A Newsweek pôs um hacker na capa, o Congresso fez audiências com o filme rodando numa tela, e em três anos os Estados Unidos tinham a lei sob a qual o crime de computador ainda é processado.
O Chaos Computer Club, o golpe do Btx e o hack que terminou numa florestaSegurança e WAFA cena hacker alemã pegou um caminho diferente da americana: organizada, política e argumentando diante das câmeras. Em 1984 o Chaos Computer Club tirou 134 mil marcos de um banco durante a noite e os devolveu na televisão. Quatro anos depois, outro grupo de Hanôver vendeu suas invasões ao KGB, e um deles morreu numa floresta aos vinte e três anos.
LOD, MOD e a Operação Sundevil: a Grande Guerra Hacker e a batida que criou a EFFSegurança e WAFDuas turmas brigaram pela rede telefônica americana por orgulho. Então o Serviço Secreto apareceu em quatorze cidades, apreendeu o manuscrito de um jogo de RPG como manual de hacking, e processou uma revista por um documento que podia ser encomendado por treze dólares. Os dois casos desabaram, e dos escombros veio a Electronic Frontier Foundation.
Phrack, 2600 e a imprensa underground: como a cena se publicou por cinquenta anosSegurança e WAFUm boletim yippie sobre enganar a companhia telefônica, em 1971. Um trimestral de três folhas com tiragem de vinte e cinco, em 1984. Um zine de BBS de St. Louis que lançou seu primeiro número em novembro de 1985 e o septuagésimo segundo, em quinze mil exemplares impressos, em agosto de 2025. Antes de conferências, programas de recompensa ou uma indústria de segurança, a cena tinha uma imprensa - e a imprensa pagou, em batidas, indiciamentos e liminares, pelo que imprimiu.
A Electronic Frontier Foundation: os advogados que construíram uma máquina de quebrar cifras e uma autoridade certificadoraSegurança e WAFComeçou com um agente do FBI na cozinha de uma fazenda no Wyoming, em 1990. Estabeleceu que código-fonte é discurso, construiu a máquina que acabou com o DES, levou a sala da rua Folsom a um tribunal e depois parou de processar pelo tempo necessário para escrever o software que fez do HTTPS o padrão. É isto que uma organização de liberdades civis fez ao trabalho diário de quem opera redes.
L0pht, cDc e o ano em que o underground entrou no SenadoSegurança e WAFEm maio de 1998 sete hackers depuseram ao Senado dos Estados Unidos sob seus apelidos e disseram que conseguiriam derrubar a internet em trinta minutos. Dois meses depois o Cult of the Dead Cow lançou o Back Orifice num palco da DEF CON para forçar a mão da Microsoft. Entre os dois, 1998 é o ano em que a cena deixou de ser subcultura e começou a virar indústria.
O worm WANK e os International Subversives: o capítulo australianoSegurança e WAFDias antes de a NASA lançar uma sonda movida a plutônio, seus computadores saudaram os operadores com um banner de protesto antinuclear. O primeiro worm hacktivista nunca foi atribuído em definitivo, mas a trilha aponta para uma cena de Melbourne que também produziu o livro Underground - pesquisado por um jovem hacker chamado Mendax, que depois fundou o WikiLeaks.
Os ataques nomeados ao TLS, 2011-2023: o que cada um quebrou, e o que o protocolo removeu por causa deleSegurança e WAFBEAST, CRIME, Lucky13, Heartbleed, POODLE, FREAK, Logjam, DROWN, SWEET32, SLOTH, ROBOT, ROCA, Raccoon, ALPACA, Terrapin. Quatorze nomes, doze anos, um padrão: cada ataque achou uma funcionalidade que o protocolo nunca deveria ter mantido, e o TLS 1.3 é a lista do que foi retirado. Este é o guia para ler um relatório de cipher suites como história.
Os manifestos: o Mentor, os cypherpunks, a Declaração e os textos que uma cultura escreveu sobre si mesmaSegurança e WAFQuatrocentas e cinquenta palavras digitadas por um garoto de dezenove anos na noite seguinte à sua prisão, em 1986. O pastiche de Marx de um criptoanarquista lido numa conferência em 1988. Sete parágrafos sobre privacidade em 1993, dezesseis sobre independência escritos num hotel em Davos em 1996, e uma página redigida na Itália em 2008 que um promotor leria mais tarde em voz alta. O que dizem os textos fundadores da cultura hacker, por que cada um foi escrito quando foi, e onde lê-los no original.
DEF CON: uma festa de despedida que virou instituição, e as camisas vermelhas que a sustentamSegurança e WAFComeçou em 1993 como festa de despedida para a rede de BBS de um amigo. Trinta anos depois enche Las Vegas com dezenas de milhares de hackers, roda com dinheiro vivo na porta, e é mantida de pé por voluntários não remunerados de camisa vermelha que pagam do próprio bolso para estar lá. Os Goons são a razão de aquilo funcionar, e a razão de ainda parecer comunidade em vez de feira de negócios.
EternalBlue, WannaCry, NotPetya: o ano em que um exploit roubado foi trabalhar para todo mundoSegurança e WAFEm abril de 2017 um grupo anônimo publicou um exploit funcional da NSA para um protocolo que roda em toda máquina Windows do mundo. A Microsoft o tinha corrigido um mês antes. Em oito semanas ele moveu os dois incidentes cibernéticos mais caros da história - um parado por um pesquisador que registrou um domínio de dez dólares, o outro imparável porque nunca foi feito para ser parado.
A série RFC: como a internet se documentaSegurança e WAFEm abril de 1969, um aluno de pós-graduação passou a limpo umas anotações sobre software de host e, com medo de parecer presunçoso, chamou o texto de Request for Comments, um pedido de comentários. Nove mil documentos depois, essa cautela ainda dá nome ao processo pelo qual foi acordado cada protocolo que você opera. O que é uma RFC, o que o status dela quer dizer de verdade e por que a numeração tem uma tradição de primeiro de abril.
Stuxnet: a primeira ciberarma, e o dia em que código quebrou máquinaSegurança e WAFUm worm carregando quatro exploits desconhecidos de Windows atravessou um air gap até uma usina de enriquecimento iraniana, girou centrífugas até a destruição e tocou aos operadores leituras normais gravadas enquanto eles olhavam as telas. Só foi achado porque escapou. Tudo o que veio depois em operações cibernéticas estatais - inclusive os vazamentos que armaram o mundo - começa aqui.
A guerra dos protocolos: como o TCP/IP venceu contra todas as expectativasSegurança e WAFTodos os governos, todas as companhias telefônicas, todos os grandes fabricantes de computadores e o Departamento de Defesa dos Estados Unidos apoiavam o OSI. A especificação era mais completa e mais rigorosa, e tinha a aprovação formal dos órgãos de padronização do mundo inteiro. Mesmo assim, perdeu para uma suíte de protocolos criada por alunos de pós-graduação e distribuída de graça, e o motivo dessa derrota é a lição mais útil deste catálogo para quem precisa escolher uma tecnologia hoje.
Anonymous, LulzSec e a década hacktivistaSegurança e WAFUm coletivo sem liderança vindo da cultura dos imageboards virou o rosto público do hacking de protesto, defendeu o WikiLeaks, entrou na Primavera Árabe, e então se fragmentou numa turma de seis pessoas que invadiu Sony, PBS e uma afiliada do FBI em cinquenta dias - enquanto seu líder já era informante. A década seguinte definiu o que um movimento sem estrutura de responsabilização consegue e não consegue fazer.
As Crypto Wars: quando criptografia era muniçãoSegurança e WAFDurante a maior parte dos anos noventa, exportar criptografia forte dos Estados Unidos equivalia juridicamente a exportar uma arma. Um programador deu de graça uma ferramenta de cifragem e enfrentou três anos de investigação criminal; uma camiseta com quatro linhas de código era item sob controle de exportação; e o governo propôs um chip que cifraria suas ligações guardando uma cópia da chave. A briga daquela década decidiu se a web moderna podia existir.
As Crypto Wars: trinta e três anos da mesma discussãoSegurança e WAFEm 1993 um governo propôs um chip de telefone cuja cifragem era forte e de cujas chaves ele guardava uma cópia. A proposta morreu em três anos. A discussão não: voltou como controle de exportação, como porta dos fundos numa norma, como ordem judicial contra um fabricante de celulares, e como uma notificação secreta a um provedor de nuvem que ainda está num tribunal. Toda rodada pergunta se acesso excepcional pode ser acrescentado a um sistema seguro, e toda rodada recebe a mesma resposta de engenharia.
2011: o ano em que as âncoras de confiança quebraramSegurança e WAFEm março, um e-mail de spear phishing com um anexo de Excel chegou à empresa cujos tokens guardavam as empreiteiras de defesa do mundo. Em junho, uma autoridade certificadora em que todo navegador do planeta confiava foi tomada, e emitiu 531 certificados fraudulentos usados para ler o correio de uns 300 mil iranianos. Os dois foram achados tarde, os dois foram comunicados mais tarde ainda, e a segunda empresa não existe mais.
O circuito latino-americano de conferências de segurança: um índiceSegurança e WAFA América Latina construiu o próprio circuito de conferências em vez de importar um - Ekoparty em Buenos Aires desde 2001, H2HC em São Paulo desde 2004, DragonJAR na Colômbia, 8.8 no Chile, RoadSec rodando as capitais brasileiras. Este é o índice: quem fundou cada uma, para que cada uma serve de fato, e como diferem dos eventos do norte com que costumam ser comparadas.
A cena brasileira: do Alternex a uma conferência por mêsSegurança e WAFA cultura hacker brasileira não começou num alojamento universitário nem numa companhia telefônica - começou numa ONG de justiça social que pôs no ar a primeira rede pública do país, e cresceu por BBSs, um underground de fraude de classe mundial, um sistema de governança incomumente aberto, e um calendário de conferências tão denso que a maioria das semanas do ano tem uma. O que é a cena, como chegou aqui, e como está agora.
Moonlight Maze, Titan Rain, Aurora: as três campanhas que ensinaram uma palavra nova à indústriaSegurança e WAFEntre 1996 e 2010, três campanhas de intrusão moveram o alvo das redes de governo para as empreiteiras que o servem e daí para as empresas de tecnologia que todo mundo usa. Uma foi achada por acaso, outra por um homem que trabalhava de madrugada e perdeu o emprego por isso, e a terceira foi anunciada pela própria vítima em seu blog - decisão que mudou como violações são divulgadas e produziu a arquitetura hoje vendida como zero trust.
A era dos worms, 1999-2008: de Melissa a Conficker, e a correção que sempre existiaSegurança e WAFSete surtos em nove anos tomaram o e-mail, depois os servidores web, depois os bancos de dados, depois qualquer máquina Windows alcançável. Em quase todos os casos a correção tinha saído semanas ou meses antes e não fora instalada - e no último, o boletim da Microsoft dizia por escrito que a falha era passível de worm. Esta é a era que produziu a atualização automática, o firewall ligado por padrão, e a discussão que a indústria ainda trava.
Cibercrime brasileiro: do boleto ao PixSegurança e WAFO Brasil bancarizou online cedo, inventou instrumentos de pagamento que o resto do mundo não tinha, e criou uma indústria criminosa moldada exatamente a eles — manipulação de código de barras, sobreposição de tela, jackpotting de caixa eletrônico, e agora engenharia social mirando transferências instantâneas. As técnicas, as quadrilhas que as exportaram, os ataques ao Estado, e as leis escritas depois de cada choque.
Não existe código perfeito: por que segurança é um relógio, não um código-fonteSegurança e WAFTodo fornecedor relevante já lançou uma falha que facilitou uma invasão, e todos vão lançar de novo. O que separa as organizações não é a densidade de defeitos - é o tempo entre o comprometimento e a detecção, a detecção e a contenção, a contenção e uma correção definitiva, e a honestidade do que se diz no meio disso. Este é o argumento, com as evidências, e uma pergunta aberta sobre o que a IA faz com os dois lados do relógio.
Por que a SSL-VPN está sendo desmontada, e o que de fato a substituiSegurança e WAFO FortiOS 7.6.3 removeu o modo túnel da SSL VPN de todo FortiGate, e as configurações existentes não são migradas na atualização. Isso é fato verificado, com consequências operacionais reais. A afirmação de que todo fornecedor está abandonando a SSL-VPN é mais complicada, e a maior parte das cronologias em circulação é publicada por empresas que vendem a substituição. Aqui está o que está estabelecido, o que é inferência, e o que um profissional deve realmente fazer.
WireGuard: o argumento de que um túnel deveria ser pequeno o bastante para ser lidoSegurança e WAFCerca de quatro mil linhas de código, uma única suíte de cifras sem negociação, nenhuma identidade de usuário, e nenhum jeito de pedir uma opção mais fraca. Foi incorporado ao núcleo do Linux em 2020 com um endosso público de Torvalds, e é o padrão dentro da maioria dos produtos hoje vendidos como acesso zero trust. Também não consegue fazer várias coisas de que uma empresa precisa, e saber quais é o ponto deste artigo.
Fiddler, Burp, Cain e os demais: as ferramentas que leem uma conversa da qual não faziam parteSegurança e WAFUm proxy de depuração, uma suíte de teste de invasão, um programa de recuperação de senhas de um site italiano de uma pessoa só, e um appliance corporativo de inspeção fazem todos a mesma operação - terminar uma conexão que as duas pontas julgam ser delas. O que os separa não é técnica, é consentimento e transparência. Onde cada um se coloca, o que derrota cada um, e por que a ferramenta em que todo mundo aprendeu sumiu da web.
Wireshark: a ferramenta que tornou os pacotes legíveis, e a pilha por baixo delaSegurança e WAFEm julho de 1998 um engenheiro de redes de um provedor pequeno de Kansas City anunciou um programa que escrevera porque os analisadores comerciais custavam mil e quinhentos dólares e não rodavam nas plataformas dele. Em dias, desconhecidos mandavam correções. Perdeu o próprio nome para uma marca registrada em 2006, sobreviveu a três patrocinadores corporativos, e é a razão de um profissional conseguir ler um protocolo que nunca viu.
KRACK e Dragonblood: o que veio depois do WEP e por que um handshake comprovadamente seguro quebrou mesmo assimSegurança e WAFO four-way handshake do WPA2 tinha passado por análise formal e sido declarado seguro. Em 2017, um pesquisador da KU Leuven quebrou esse handshake mesmo assim, fazendo o cliente reinstalar uma chave que ele já estava usando. O substituto, o WPA3, saiu em 2018 e foi quebrado pelo mesmo pesquisador em 2019. Nenhuma das falhas estava na cifra, e essa é a lição inteira.
A falha de Kaminsky: o verão em que oitenta fabricantes corrigiram o mesmo bug no mesmo diaSegurança e WAFEm 2008, um pesquisador percebeu que uma fraqueza já conhecida do DNS era muito mais grave do que se calculava: ela não servia só para envenenar um registro, mas para tomar um domínio inteiro em segundos, quantas vezes o atacante quisesse. Veio então o maior patch coordenado que a internet já tinha tentado, uma correção que trouxe mais entropia, e não certeza, e um lembrete de que publicar um patch também é publicar a vulnerabilidade.
Reflections on Trusting Trust: a palestra de 1984 que previu todo ataque de cadeia de suprimento desde entãoSegurança e WAFKen Thompson usou sua palestra do Prêmio Turing para explicar que pusera uma porta dos fundos no compilador C que se reinseria toda vez que o compilador era reconstruído - e depois apagou a evidência do código-fonte. Ler o fonte nunca acharia aquilo. Quarenta e dois anos depois existe exatamente um método que o derrota formalmente, e a razão de o XZ Utils e a 3CX terem funcionado é que quase ninguém o usa.
Mirai: a botnet que não explorou nadaSegurança e WAFTrês estudantes de vinte e poucos anos a construíram para vencer no negócio de hospedar servidores de Minecraft, e ela produziu os maiores ataques que a internet já vira. Não usou vulnerabilidade nenhuma. Ela fez login, com uma lista de umas sessenta senhas de fábrica, em câmeras e roteadores cujos donos não sabiam ter uma conta. Não dá para corrigir um padrão de fábrica, e é por isso que o conserto acabou sendo uma lei.
Autoridades certificadoras: o cadeado é uma lista de gente que você nunca conheceuSegurança e WAFSeu navegador confia em algumas centenas de organizações para atestar quem é dono de qual nome, e qualquer uma delas pode emitir um certificado válido para qualquer site da internet. Esse desenho já falhou em público pelo menos uma vez de forma grave o bastante para acabar com uma empresa e expor os dissidentes de um país. O que quebra quando uma AC é comprometida, por que a revogação mal funciona, e como a indústria trocou confiança por vigilância de si mesma.
Target, 2013: os alertas dispararam, e ninguém se moveuSegurança e WAFUm empreiteiro de ar-condicionado na Pensilvânia abriu um e-mail de phishing. Seis semanas depois, um malware nos caixas de 1.797 lojas lia cartões de pagamento da memória durante as três semanas mais movimentadas do ano no varejo. A ferramenta de segurança detectou e alarmou enquanto acontecia. É essa a parte que vale ensinar, porque nada nesta invasão foi falha de tecnologia.
Y2K: o que custa estar certo sobre um desastre que então não aconteceSegurança e WAFGastou-se algo entre duzentos e seiscentos bilhões de dólares, a meia-noite passou, quase nada quebrou, e quem fez o trabalho vem sendo chamado de charlatão desde então. O relato honesto é mais interessante que a versão de qualquer um dos lados: parte do medo era fundamentada, parte comprovadamente não era, e uma comparação nunca foi respondida de forma satisfatória.
Unix: o sistema operacional dentro de toda caixa da sua redeSegurança e WAFEntre num balanceador de carga, num firewall ou num ponto de acesso e olhe embaixo da interface de gerência. Há um sistema de arquivos, um shell, syslog, cron e tcpdump. O appliance é um Unix com um produto por cima, e é assim por causa de um acordo antitruste de 1956 que impediu uma companhia telefônica de vender software.
Autenticação de e-mail: o que SPF, DKIM e DMARC de fato fazemSegurança e WAFO e-mail foi desenhado sem nenhuma forma de conferir quem enviou, e os três registros que todo mundo publica resolvem metades diferentes desse problema — mal explicados, frequentemente mal configurados, e rotineiramente creditados com uma proteção que não oferecem. O que cada um confere, por que alinhamento é a ideia que importa, por que encaminhamento quebra tudo, e a ordem de implantação que de fato chega à aplicação.
Shellshock e Log4Shell: quando a vulnerabilidade é uma funcionalidadeSegurança e WAFNenhum dos dois foi erro de memória. Nos dois casos um componente amplamente usado fez exatamente o que sua documentação dizia, com uma cadeia de caracteres vinda de um estranho. Um ficou no bash por uns vinte e dois anos sem ser descoberto; o outro transformou o registro em log - a única coisa que toda aplicação faz com entrada não confiável - em execução remota de código. Esta é a classe de falha que testar em busca de travamentos nunca vai achar.
Diffie-Hellman explicado sem matemáticaSegurança e WAFDuas pessoas que nunca se viram, gritando numa sala cheia onde todos ouvem tudo, terminam a conversa sabendo um número secreto que ninguém mais na sala sabe. Parece truque. É a única ideia que torna possível comprar algo pela internet, e aqui está como funciona, com uma equação e nenhum conhecimento prévio.
Passkeys: por que este MFA é diferente do MFA que segue falhandoSegurança e WAFA maior parte da autenticação multifator impede reúso de senha e não faz nada contra phishing, porque tudo o que o usuário consegue ler e digitar pode ser retransmitido por um atacante em tempo real. As passkeys fecham isso amarrando a credencial à origem do site, dentro do navegador. O que o WebAuthn de fato faz, por que a amarração à origem é o truque inteiro, e os problemas de recuperação e ciclo de vida que ninguém resolveu ainda.
Backups: o controle que precisa funcionar quando todos os outros já falharamSegurança e WAFO ransomware transformou o backup de preocupação de disponibilidade na última linha de defesa, e então foi atrás dos próprios backups. O que mudou, por que a velha regra 3-2-1 precisa de uma quarta cláusula, por que uma restauração não testada é boato, e o fato incômodo de que o backup resolve a metade da cifragem num ataque moderno de extorsão e nada da metade da divulgação.
Therac-25: a máquina cujo antecessor tinha os mesmos defeitos e não feriu ninguémSegurança e WAFEntre 1985 e 1987 uma máquina de radioterapia aplicou doses maciças em excesso a pelo menos seis pacientes. O defeito de software era grave. O achado que fez daquilo o caso mais ensinado da engenharia de software é outro, e pior: o modelo anterior rodou código comparavelmente defeituoso por anos sem ferir ninguém, porque tinha um hardware que não deixava.
DDoS: por que a defesa é capacidade, e por que a amplificação é culpa dos outrosSegurança e WAFNegação de serviço não é um ataque, são três problemas com respostas diferentes: um cano que enche, uma tabela de estado que esgota, e uma requisição cara repetida de forma barata. Os maiores ataques só são possíveis porque as redes de terceiros deixam sair tráfego forjado — o que faz da mitigação mais eficaz algo que se implanta para estranhos, e não para si.
O ataque ao STJ, 2020: a quinzena em que a segunda mais alta corte do Brasil parouSegurança e WAFEm 3 de novembro de 2020 um ransomware cifrou o acervo de processos do Superior Tribunal de Justiça. Sessões foram canceladas, prazos processuais foram suspensos por resolução, e os sistemas voltaram quinze dias depois. Fazia parte de uma onda contra o Judiciário brasileiro, e os relatos sobre o que aconteceu com os backups nunca foram reconciliados.
SATAN, 1995: o scanner que fez seu autor ser demitidoSegurança e WAFDois pesquisadores construíram um programa que achava falhas de segurança numa rede, explicava cada uma em linguagem clara e dizia como consertar. Antes do lançamento a imprensa previu desastre, um laboratório nacional se preparou para uma invasão, e a Silicon Graphics demitiu um dos autores. A indústria então passou trinta anos concordando com ele, e a discussão acaba de recomeçar.
Zero trust, ZTNA e SASE: o que os termos significam quando se tira o marketingSegurança e WAFZero trust é um princípio de arquitetura, ZTNA (acesso à rede zero trust) é um jeito de publicar aplicações, e SASE (borda de serviço de acesso seguro) é um arranjo de compra. Os fabricantes embaralham os três porque a confusão vende. Aqui está o que cada um de fato é, o que muda de verdade ao adotá-los, e a lista honesta do que eles não resolvem.
Ariane 5: o código estava correto, e o mundo tinha mudadoSegurança e WAFQuarenta segundos depois do primeiro voo o foguete se destruiu. O software que o matou funcionava exatamente como escrito e voara com sucesso muitas vezes no modelo anterior. Ele calculava algo que não era necessário depois da decolagem, a partir de uma rotina que ninguém pensara em desligar, usando uma premissa que fora verdadeira de outro foguete.
Knight Capital: quarenta e cinco minutos, e um rollback que espalhou o defeitoSegurança e WAFUma corretora responsável por um décimo do volume de ações americano implantou código novo em sete dos seus oito servidores. O oitavo ainda guardava uma função morta desde 2005, ligada a uma flag que o código novo reaproveitara. Noventa e sete e-mails de aviso saíram antes de o mercado abrir. E quando os engenheiros entenderam o que acontecia, fizeram rollback - pondo o código defeituoso nos oito.
SIEM: por que custa tanto e detecta tão poucoSegurança e WAFUm SIEM é um banco de dados com uma caixa de busca e um agendador. Sozinho ele não detecta nada, e a maioria das implantações falha do mesmo jeito — comprada como produto, custeada como projeto, alimentada com tudo, ajustada por ninguém. O que faz diferença é tratar detecções como artefatos de engenharia, com dono, teste e resposta documentada.
Schrems II: o dia em que um tribunal leu o registro da vigilância e tirou uma conclusãoSegurança e WAFEm 2020 a mais alta corte da Europa derrubou a base jurídica que cinco mil empresas americanas usavam para mover dados pessoais pelo Atlântico. Seu raciocínio não era sobre contratos. Era sobre o que a lei de inteligência dos Estados Unidos de fato permite, e se um europeu cujos dados fossem coletados sob ela teria onde reclamar. A consequência de engenharia é a parte que os profissionais mais erram.
O e-mail de 500 milhas: a melhor história de debugging da profissãoSegurança e WAFUm departamento de estatística avisou que não conseguia mandar e-mail para mais longe que umas 520 milhas. A primeira reação do sysadmin foi dizer que e-mail não funciona assim. O departamento tinha um mapa. A causa era um arquivo de configuração, um upgrade, um timeout configurado em zero e a velocidade da luz, e cada um desses elementos ainda pode acontecer com você hoje à tarde.
A Silk Road: a rede de anonimato aguentou, o operador nãoSegurança e WAFO Tor nunca foi quebrado. O fundador do site foi identificado porque em 2011 anunciara o mercado em fóruns públicos sob um apelido, e uma dessas postagens trazia o e-mail real dele. Como os investigadores acharam o servidor é outra pergunta, e uma que um tribunal se recusou a responder - porque respondê-la exigiria que o réu admitisse que o servidor era dele.
You Sh0t the Sheriff: o podcast que virou a conferência de segurança mais exclusiva do BrasilSegurança e WAFTrês pessoas em três cidades começaram um podcast de segurança em 2006. O evento veio depois, e herdou o formato do podcast: pequeno de propósito, só por convite, com o local mantido em segredo até a confirmação. Duas décadas depois, o podcast continua gravando e a conferência já pôs Jeff Moss e o Space Rogue no mesmo palco de quem escreveu as ferramentas brasileiras.
O defeito FDIV do Pentium: um erro pequeno e uma resposta de 475 milhões de dólaresSegurança e WAFCinco entradas faltando numa tabela de consulta deixavam certas divisões ligeiramente erradas. A Intel achara o defeito internamente, decidira que ele não qualificava sequer como errata, o consertara em silêncio e nada disse. Quando um professor de matemática o achou por conta própria, a empresa ofereceu troca apenas a clientes que provassem ter sido afetados - e transformou uma falha aritmética rara no recall mais famoso da computação.
Segurança contra disponibilidade: a troca que ninguém escreveSegurança e WAFTodo controle de segurança é também um jeito novo de o sistema parar. A tríade põe confidencialidade, integridade e disponibilidade no mesmo pé, e as organizações então as separam em áreas, medem em separado, e descobrem o conflito durante um incidente. A história da troca, onde ela é decidida na prática, os modos de falha dos dois lados, e como equipes maduras a precificam antes da queda, e não depois.
Mars Climate Orbiter: os dois lados estavam certos, e a espaçonave se perdeuSegurança e WAFUm programa produzia valores de impulso em libras-força-segundo. O programa que os consumia esperava newtons-segundo. Nenhum estava errado internamente, a especificação dizia qual era exigido, e nada conferia. A versão famosa desta história é uma conversão de unidades; a versão útil é o que acontece numa fronteira entre duas organizações, e o que a equipe fez com quatro meses de aviso.
Segurança por obscuridade: o que Kerckhoffs de fato disseSegurança e WAFA máxima é citada como proibição de esconder qualquer coisa, o que não é o que ela diz nem o que o campo pratica. Kerckhoffs em 1883, e Saltzer e Schroeder em 1975, faziam uma afirmação mais estreita e mais afiada sobre de qual segredo um sistema pode depender. A história, a diferença entre um segredo e uma obscuridade, onde cada um é legítimo, e os sistemas que provaram o ponto ao serem quebrados assim que alguém olhou.
Como os sistemas falham: um mapa de leitura para os casos deste catálogoSegurança e WAFNove falhas, ordenadas não por setor ou década, mas por onde a falha de fato morava - numa salvaguarda que alguém removeu, numa premissa que venceu, num rollback, numa fronteira entre duas organizações, numa decisão sobre o que dizer. Lidas como conjunto, deixam de ser anedotas e viram uma lista dos lugares onde procurar.
O firewall: nascimento, gerações, e o que vem depois do perímetroSegurança e WAFNinguém inventou o firewall. Ele foi discutido até existir, ao longo de uns seis anos, por gente da Digital Equipment Corporation, do Bell Labs e da Trusted Information Systems que discordava de quase tudo, menos de que uma rede precisava de um lugar para dizer não. Esta é a história da família: o artigo de 1988, o primeiro produto entregue em 13 de junho de 1991, a patente de inspeção com estado que decidiu o mercado, o campo dos proxies que perdeu no desempenho e estava certo sobre inspeção, o appliance, o rótulo de próxima geração, e o que acontece com um equipamento de fronteira num parque que não tem mais fronteira.
O registro da divulgação: o que houve entre achar e dizerSegurança e WAFTodo caso deste catálogo tem um intervalo dentro - entre o momento em que alguém soube e o momento em que os outros souberam. Às vezes foram seis horas e às vezes foi uma década. Esta página reúne os casos em que esse intervalo decidiu o desfecho, e o que cada um estabeleceu sobre coordenar, reter, publicar e ser acreditado.
O fio brasileiro: seis artigos que só fazem sentido juntosSegurança e WAFUma reserva de mercado que produziu clones e contrabando, um modelo de governança que era multissetorial antes de a palavra existir, uma cultura hacker que começou numa ONG de justiça social, uma indústria criminosa moldada para instrumentos de pagamento que nenhum outro país tinha, uma lei de dados com dez bases legais e um prazo de três dias, e a quinzena em que um tribunal superior parou. Separados, são fatos de país. Em ordem, são um argumento sobre o que acontece quando um país grande constrói a própria internet.
Detecção de intrusão: a disciplina construída sobre ler os registrosSegurança e WAFA detecção de intrusão começou como problema de arquivo. O relatório de James Anderson, de 1980, propunha auditar os registros de um computador para achar uso anormal; Dorothy Denning e Peter Neumann transformaram aquilo num modelo em tempo real entre 1984 e 1986; Todd Heberlein levou a ideia para o fio em 1990; e Marty Roesch a deu de graça em 1998. Esta é a história da família, inclusive a divisão entre detecção e prevenção, que foi decisão de negócio tanto quanto técnica, e por que o problema mais difícil da área sempre foi a pessoa que precisa ler a saída.
O firewall de aplicação web: comprado por auditores, culpado por engenheirosSegurança e WAFO primeiro firewall de aplicação web e o primeiro scanner de aplicação web foram construídos pela mesma empresa, e esse é o fato estrutural que costuma faltar quando esta família é explicada. O AppShield saiu no verão de 1999; o ModSecurity abriu a categoria em 2002; o OWASP Top 10 deu vocabulário a ela em 2003; e o PCI DSS a transformou em compra em 2004. Esta é a história da família, inclusive por que uma tecnologia com vinte e cinco anos de desenvolvimento ainda é descrita pelos próprios órgãos profissionais como uma caixa preta mágica que faz segurança.
SAST e DAST: duas linhagens, uma linha de orçamentoSegurança e WAFTeste estático e teste dinâmico de segurança de aplicação são vendidos como par e descendem de lugares completamente diferentes. O SAST vem do lint, escrito no Bell Labs em 1978 para resolver um problema de portabilidade e só depois apontado para segurança. O DAST vem do ferramental de ataque do fim dos anos 1990, construído pela mesma empresa que fez o primeiro firewall de aplicação web. Esta é a história da família, inclusive por que o nome da ferramenta fundadora virou xingamento, e por que as duas abordagens discordam por construção, e não por qualidade.
Cifragem: o padrão, a suspeita, e o que a suspeita errouSegurança e WAFA criptografia civil tem um documento fundador e uma discussão fundadora. O documento é o Data Encryption Standard, emitido em janeiro de 1977 a partir de uma cifra que a IBM construiu sobre o Lucifer de Horst Feistel. A discussão é o que a National Security Agency fez com ele - e a resposta, que levou dezessete anos para aparecer, é que a agência tornou o algoritmo mais forte contra um ataque que ninguém de fora conhecia, ao mesmo tempo que encurtou a chave. Esta é a história da família: de um nome de arquivo longo demais para um sistema operacional, passando pelas guerras da criptografia, até um processo de padronização que hoje roda aberto por causa do que aquela suspeita custou.
O módulo de segurança em hardware: o homem que inventou as duas metadesSegurança e WAFMohamed Atalla inventou o MOSFET no Bell Labs, viu a invenção ser ignorada, pediu demissão, e doze anos depois inventou o módulo de segurança em hardware. A tecnologia de transistor que tornou a computação moderna possível e a caixa que protege os segredos mais valiosos dela vieram da mesma pessoa - e ele precisou sair do principal laboratório de pesquisa do mundo para construir a segunda. Esta é a história da família: a Caixa Atalla de 1973, um padrão criado por medo de que uma empresa dominasse, um nível de garantia que quase ninguém alcança, e o que acontece quando a resposta à gestão de chaves se muda para a nuvem de outra pessoa.
Identidade: o L de LDAP é uma discussãoSegurança e WAFO X.500 era um bom modelo de dados embrulhado num protocolo que ninguém conseguia implantar. Em julho de 1993, três engenheiros publicaram uma especificação cuja premissa inteira era jogar a maior parte dele fora, e chamaram o resultado de Leve. Esta é a história da família da identidade - do arquivo de senha por máquina ao NIS, X.500, LDAP, Kerberos, SAML e OpenID Connect - e a discussão que atravessa tudo isso: se identidade é algo que a rede afirma, algo que um diretório guarda, ou algo por que um terceiro se responsabiliza.
PKI: uma monografia de graduação, e um modelo de confiança que ninguém projetaria hojeSegurança e WAFEm maio de 1978, um aluno de graduação do MIT escreveu uma monografia que nomeou o certificado, nomeou a lista de revogação e desenhou a estrutura sobre a qual a web ainda roda. O que cresceu em volta é um modelo de confiança que ninguém proporia do zero: cerca de cem emissores confiáveis, qualquer um deles capaz de se responsabilizar por qualquer nome da internet, com o mais fraco definindo a força para todo mundo. Esta é a história da família - Kohnfelder em 1978, X.509 em 1988, os comprometimentos de 2011, o Certificate Transparency como resposta, e um preço que caiu de centenas de dólares para nada.
Negação de serviço: a palestra interrompida pelo próprio assuntoSegurança e WAFEm fevereiro de 2000, Steven Bellovin estava havia cinco minutos numa palestra de abertura sobre ataques de negação de serviço quando os pagers começaram a tocar e a sala esvaziou. O ataque em curso tinha sido lançado por um garoto de quinze anos usando ferramentas que ele não escreveu. Esta é a história da família - o Trinoo em 1999, a semana que derrubou Yahoo, Amazon, eBay e CNN, o padrão de amplificação que este catálogo já documentou três vezes, e por que a única defesa real é capacidade que ninguém sustenta sozinho.
Correio eletrônico: um projeto paralelo que virou a camada de identidadeSegurança e WAFO empregador de Ray Tomlinson não pediu que ele construísse o correio eletrônico. Ele estava, nas palavras de um colega, só brincando, procurando o que fazer com a ARPANET - e montou aquilo a partir de uma ferramenta local de mensagens e um programa de transferência de arquivos. A especificação escrita onze anos depois permitiu que o remetente mostrado a um humano fosse diferente do remetente declarado ao servidor, que é a decisão de projeto que criou o phishing. Esta é a história da família, e ela termina com a exceção mais clara a uma regra que este catálogo julgava ter estabelecido.
Controle de acesso à rede: a ideia que chegou cedo demais, duas vezesSegurança e WAFO controle de acesso à rede não nasceu para a rede local. Nasceu em 1984, na BBN, para o equipamento ao qual você se conectava por discagem, e foi criado para as pessoas se autenticarem menos, e não mais. Esta é a história da família: do terminal access controller à autenticação do acesso discado e ao 802.1X, depois o fabric orientado a conexão da Cabletron, o ciclo da Enterasys que detectava, localizava, continha e remediava sozinho, a década em que a ideia toda foi declarada um fracasso e a volta dela com um nome que vende melhor.
Como um proxy sabe quem você é: métodos de autenticação de usuário inlineSegurança e WAFPolítica por usuário é a promessa inteira de um proxy inline - o que significa que o proxy precisa prender uma identidade a cada fluxo, inclusive aos que não conseguem fazer login. Os quatro padrões que funcionam: desafios explícitos 407, autenticação web por cookie, identidade afirmada por agente, e o compromisso do surrogate IP - mais onde cada um quebra, porque todos eles quebram em algum lugar.
Data loss prevention: como máquinas reconhecem segredosSegurança e WAFTodo produto de DLP responde à mesma pergunta - este conteúdo de saída é sensível? - com os mesmos quatro instrumentos: padrões, dicionários, correspondência exata contra registros com fingerprint e correspondência de documentos indexados. O que cada instrumento consegue e não consegue reconhecer, por que existem confiança e proximidade, e por que a parte difícil do DLP nunca foi a correspondência.
Detonação em sandbox: como julgar um arquivo pelo que ele fazSegurança e WAFAssinaturas reconhecem malware que já foi visto; um sandbox condena malware que não foi - executando o arquivo numa jaula instrumentada e observando seu comportamento. O que a detonação realmente observa, por que vereditos levam minutos, a janela de paciente-zero que o tempo cria, como o compartilhamento de hashes transforma um veredito na proteção de todos, e a corrida armamentista de evasão que mantém os construtores de jaulas empregados.
Isolamento de navegador: quando não dá para confiar na página, mova o navegadorSegurança e WAFO Remote Browser Isolation para de perguntar se uma página é segura e remove a pergunta: o navegador real roda num contêiner descartável na nuvem, e o endpoint recebe apenas uma projeção renderizada - pixels ou um DOM reconstruído. O que cada modo de renderização troca, por que isolamento é a resposta para o meio incategorizável, o que custa, e onde ficam seus limites honestos.
CORS explicado: o controle de fronteira do navegadorSegurança e WAFWeb e HTTPCORS é a mensagem de erro mais mal-entendida do desenvolvimento web, porque pune o modelo mental errado. Ele não é o muro - a same-origin policy é o muro; CORS é a porta: um protocolo de cabeçalhos pelo qual um servidor se oferece: 'aquela outra origem pode ler minhas respostas'. Requisições simples vs preflights, o que o OPTIONS está fazendo na sua aba de rede, por que credenciais apertam cada regra, por que '*' não é o conserto, e por que o CORS nunca protegeu o servidor, para começo de conversa.
Filtros de busca LDAP: como ler os parêntesesSegurança e WAFIdentidade e tokensToda consulta a diretório - PingDirectory, Active Directory, qualquer servidor LDAP - se resume a uma string de filtro em notação prefixada. Como lê-la: os operadores, os seis tipos de correspondência, os escapes, os famosos OIDs de bit-filter do AD, e por que um filtro sem índice pode derrubar um diretório.
Fluxos OAuth: como escolher o grant em 2026Segurança e WAFIdentidade e tokensUma decisão inicia toda integração: qual fluxo. A resposta moderna é curta - authorization code + PKCE para humanos, client credentials para máquinas, device grant para TVs - e as razões pelas quais implicit e ROPC morreram valem saber de cor. A RFC 9700 finalmente escreveu tudo isso.
Segurança de memória: as classes de bug e as defesas que respondem a elasSegurança e WAFEstouro de buffer, use-after-free, desreferência de ponteiro nulo, estouro de inteiro - quatro nomes para duas falhas, ficar dentro de um objeto e só tocá-lo enquanto está vivo. Como cada uma funciona, por que cerca de setenta por cento das vulnerabilidades sérias em grandes bases de código C e C++ pertencem a esta família, e o que cada camada defensiva de fato compra.
Tor: como o roteamento em cebola realmente funciona, e o que ele não protegeSegurança e WAFO roteamento em cebola foi inventado num laboratório da Marinha dos EUA, e esse paradoxo é a chave para entendê-lo: anonimato só funciona se a multidão for diversa. Como um circuito de três saltos é construído, o que são de fato os serviços onion, o modelo de ameaças que o Tor admite abertamente perder, e por que a maior parte do tráfego Tor nunca toca a dark web.
Listas de bloqueio no DNS: RPZ, classificação de domínios e o custo de uma resposta recusadaSegurança e WAFBloquear um domínio no resolver é o controle de segurança mais barato que existe, e por isso todo fabricante vende um. Como funcionam os feeds de RPZ, o que a classificação de DNS de um fabricante avalia de fato, os dois modos de falha que ninguém planeja e por que o bloqueio que você não vê é pior do que o que você vê.
O comprometimento da SolarWinds: como uma atualização assinada virou o maior ataque à cadeia de suprimentos já registradoSegurança e WAFA partir de setembro de 2019 um intruso ficou dentro do sistema de build da SolarWinds, testou em outubro e, a partir de fevereiro de 2020, inseriu um backdoor na plataforma de monitoramento Orion que a própria SolarWinds assinou e distribuiu. Menos de 18.000 clientes o instalaram; um punhado foi invadido de fato. Descoberto em dezembro de 2020 por uma vítima que investigava a própria invasão, atribuído ao SVR russo em abril de 2021 e ainda em juízo em 2024 pelo que a empresa dissera sobre a própria segurança.
Desvio de tráfego e man-in-the-middle: a família de ataques e a jogada que todos têm em comumSegurança e WAFUm mapa das formas de fazer o tráfego passar por onde não deveria, com a defesa que responde a cada uma. Todos os métodos, do ARP poisoning numa LAN ao BGP hijack na internet, são variações de uma única jogada: virar o caminho. Este artigo de abertura explica o princípio comum, organiza os métodos pela camada em que atuam e leva ao passo a passo de cada um, sempre com a mitigação padrão ao lado, porque, num site de treinamento, entender um ataque serve para reconhecê-lo e detê-lo.

Texto e utilitários (1)

ArtigoTemaResumo
O alfabeto grego: o segundo alfabeto da engenhariaTexto e utilitáriosPor que Ω significa ohm, μ significa micro e λ comanda tanto comprimentos de onda quanto funções serverless. As 24 letras, a regra do sigma final e as pegadinhas de transliteração entre o grego moderno e o clássico que silenciosamente renomeiam beta e eta.

TLS e transporte (12)

ArtigoTemaResumo
Anatomia de uma suíte de cifra TLSTLS e transporteO que uma suíte de cifra TLS realmente nomeia, como ler uma suíte como TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 parte por parte, e como o mesmo ponto de código de dois bytes aparece sob três convenções de nomes diferentes.
Como ler nomes de suítes de cifra: IANA, OpenSSL e GnuTLSTLS e transportePor que a mesma suíte de cifra tem três nomes diferentes e um ponto de código de dois bytes, como traduzir entre as convenções da IANA, do OpenSSL e do GnuTLS, e o que a coluna Recommended da IANA, com Y, N e D, realmente significa.
AEAD vs CBC: por que o modo de operação faz diferençaTLS e transporteA diferença prática entre uma cifra AEAD, como o AES-GCM, e uma cifra CBC mais antiga com um HMAC separado; os ataques de padding oracle que enterraram o MAC-then-encrypt; e o único trade-off que o AEAD ainda exige de você.
Forward secrecy e a troca de chavesTLS e transporteO que a forward secrecy garante, por que o transporte de chave com RSA estático não oferece essa garantia, como o ECDHE e o DHE oferecem, e por que autenticação e troca de chaves são duas tarefas diferentes, que o nome da cipher suite mantém separadas.
Suítes de cifra do TLS 1.3: o que mudouTLS e transportePor que uma suíte de TLS 1.3 nomeia apenas uma cifra e um hash, para onde foram a troca de chaves e a autenticação, e por que a lista de suítes encolheu de centenas para um punhado.
O que um computador quântico quebraria, e o que não quebrariaTLS e transporteUm computador quântico grande não enfraqueceria toda a criptografia por igual. O algoritmo de Shor quebra por completo a matemática de chave pública por trás de RSA, Diffie-Hellman e curvas elípticas; o algoritmo de Grover apenas reduz pela metade a força de cifras simétricas e hashes, o que AES-256 e SHA-384 já suportam. Este artigo explica a divisão, por que 'colher agora, decifrar depois' torna isso um problema de hoje, e por que um candidato quebrado como o SIKE é um lembrete de humildade.
Os padrões pós-quânticos do NIST: ML-KEM, ML-DSA e SLH-DSATLS e transporteEm agosto de 2024 o NIST finalizou os três primeiros padrões pós-quânticos: FIPS 203 (ML-KEM, do Kyber) para estabelecimento de chaves, e FIPS 204 (ML-DSA, do Dilithium) e FIPS 205 (SLH-DSA, do SPHINCS+) para assinaturas. Este artigo explica para que serve cada um, por que há dois padrões de assinatura sobre matemáticas diferentes, e onde o HQC e o FN-DSA entram como reservas ainda a caminho.
Troca de chaves híbrida no TLS 1.3: o que o X25519MLKEM768 faz na redeTLS e transporteA web não trocou a troca de chaves clássica pela pós-quântica: ela usa as duas ao mesmo tempo. O X25519MLKEM768 junta uma curva elíptica dos anos 1990 com o ML-KEM-768, baseado em reticulados, num único grupo do TLS 1.3, e assim a sessão continua segura mesmo que um dos dois seja quebrado. Por que híbrido em vez de substituição, o formato das mensagens e o problema de tamanho que ele traz, e em que pé está a implantação em navegadores, servidores e nos middleboxes que ele quebra.
TLS de entrada: offload, bridging e passthrough no reverse proxyTLS e transporteCertificados e PKIUm reverse proxy que recebe HTTPS de entrada tem três opções para a sessão TLS: terminá-la e mandar texto claro ao backend (offload), terminá-la e criptografar de novo até o backend (bridging) ou encaminhar os bytes criptografados sem mexer neles (passthrough). Cada opção equilibra visibilidade, confidencialidade e custo de um jeito diferente. Este artigo explica as três, por que o proxy tem o certificado do servidor e o que o SNI e o TLS mútuo mudam.
TLS 1.2 vs TLS 1.3 vs DTLS vs QUIC: uma família de handshakes em quatro formatosTLS e transporteO TLS 1.2 e o TLS 1.3 protegem um fluxo TCP, o DTLS oferece as mesmas garantias sobre datagramas e o QUIC trouxe o handshake do TLS 1.3 para dentro do próprio transporte. O que é cada um, qual RFC define cada um hoje, o que realmente mudou entre eles e onde cada um é usado.
O que é um fingerprint TLS JA4?TLS e transporteSegurança e WAFComo um ClientHello TLS vira uma impressão digital estável do software cliente, por que o JA3 perdeu força quando os navegadores passaram a embaralhar a ordem das extensões, como o JA4 resolve isso ordenando antes de fazer o hash, e o que o JA4 pode e não pode dizer.
Por que dizemos SSL quando queremos dizer TLS?TLS e transporteO SSL foi proibido, descontinuado e está morto há anos - e a indústria ainda vende 'certificados SSL', configura 'inspeção SSL' e linka o openssl. A história explica o hábito: o SSL da Netscape, a renomeação política para TLS em 1999 (o campo de versão no fio ainda dizia 3.1), e um quarto de século de inércia de marketing. Mais a reflexão que a pergunta merece: como seria um nome independente de protocolo, e algum já existe?

Web e HTTP (9)

ArtigoTemaResumo
Requisição HTTP crua: como ler e transformar de volta em algo que rodaWeb e HTTPUma captura, um log de proxy e um exemplo de RFC entregam a mesma coisa: uma linha de requisição, alguns headers e talvez um body. Transformar isso de volta num comando que roda parece mecânico, mas tem três armadilhas: a URL não está na mensagem, alguns headers não podem ser copiados e o que você colou costuma ser uma credencial válida.
Como funciona uma ferramenta em WebAssembly: o que roda, de onde vem e o que sai da páginaWeb e HTTPOperações e fieldcraftA maioria das ferramentas deste site são pequenas funções puras escritas aqui e testadas com vetores de ouro. Um playground de Python não pode ser isso: o que você quer é um interpretador de verdade, e a forma honesta de oferecer um em um site estático é o CPython compilado para WebAssembly, baixado pelo seu navegador e executado na sandbox dele. Este artigo explica o que muda quando uma ferramenta roda código de terceiros: o download e por que ele espera a sua autorização, o Worker e por que Parar é um encerramento, a Content Security Policy e o que foi medido contra ela, os arquivos fixados e seus resumos, o relógio de parede, e quais verificações são do site e quais são do motor. Com a documentação do próprio motor citada em cada afirmação.
Mensagens escondidas em headers HTTP: homenagens, piadas e vagas de emprego no overheadWeb e HTTPSegurança e WAFO HTTP deixa o servidor acrescentar o header que quiser, e há vinte anos operadores usam essa liberdade para coisas que não são protocolo. Depois que Terry Pratchett morreu, em 2015, milhares de sites passaram a enviar X-Clacks-Overhead: GNU Terry Pratchett, uma homenagem criada a partir de um recurso da trama de um romance do próprio autor. O Slashdot respondia a cada requisição com uma citação de Futurama. A Automattic e o Airbnb esconderam ofertas de emprego onde só quem lê headers ia ver. Um cache de páginas se anuncia com o tema do Batman. Dois códigos de status levam piadas literárias para dentro do próprio padrão. Este artigo passa por cada caso, mostra a evidência e explica o que os bons exemplos têm em comum: não custam nada a quem lê, são verdadeiros e são feitos para quem olha. No fim, mostra como você mesmo pode lê-los e quais são os deste site.
Contraste de cor: a aritmética do WCAG e as dez maneiras de o CSS escrever uma corWeb e HTTPCodificação e dadosSe um texto pode ser lido sobre o seu fundo é, no WCAG, um único número calculado a partir de duas cores, e o cálculo é curto o bastante para se fazer à mão uma vez. Aqui está a aritmética (luminância relativa, a razão, os limiares de 4.5:1 e 3:1 e de onde vêm), seguida das notações em que o CSS Color Level 4 permite escrever uma cor, de #hex a oklch(), e por que as mais novas tornam um par reprovado mais fácil de corrigir.
Especificidade, contada pela especificação, e as cinco coisas que a cascata verifica antesWeb e HTTPToda guerra de folhas de estilo acaba no mesmo lugar: duas regras querem a mesma propriedade no mesmo elemento e uma vence. O CSS decide com um procedimento curto e exato, e a especificidade é só o quinto passo. Aqui está como o Selectors Level 4 conta um seletor em três números, o que :is(), :where(), :not() e :nth-child(of) fazem com a conta, os dez exemplos que a própria especificação dá, e os cinco critérios que a cascata resolve antes de olhar para a especificidade.
Onde uma mensagem HTTP/1.1 termina: Content-Length, chunked e as oito regrasWeb e HTTPRedesUma conexão HTTP/1.1 é um fluxo de bytes com mensagens postas uma após a outra, e nada marca onde uma para além das regras que as duas pontas combinam. A RFC 9112 dá oito delas, em ordem de precedência, e todo ataque de request smuggling dos últimos vinte anos são duas implementações aplicando regras diferentes aos mesmos bytes. Aqui estão as regras, a codificação chunked decodificada à mão, o que o Content-Length promete e o que dá errado quando a promessa e os bytes discordam.
Como o parser de HTML repara a sua marcação, e por que os reparos são iguais em todos os navegadoresWeb e HTTPSegurança e WAFUm navegador nunca rejeita HTML. Seja o que for que você cole, uma árvore sai, e o HTML Standard diz exatamente qual árvore: os elementos que o parser cria por você, as tags de fechamento que ele supre, os elementos de formatação que divide, o conteúdo que tira de dentro das tabelas, os comentários que faz dos seus erros de digitação, e o quirks mode em que cai sem um DOCTYPE. Os 52 erros de análise nomeados, os cinco reparos que vale conhecer pelo nome, em que view source e inspecionar elemento discordam, e por que a WCAG 2.2 pôde abandonar o seu critério de análise sem baixar a régua.
Como um seletor encontra os seus elementos: o Selectors Level 4 lido como um algoritmo de casamentoWeb e HTTPUm seletor CSS é uma pergunta feita a uma árvore, e a especificação diz exatamente como a pergunta é respondida: composto por composto, da direita para a esquerda, com a linguagem do documento decidindo o que conta como o mesmo nome. Onde a caixa importa e onde não importa, os sete operadores de atributo e a string vazia que não casa com nada, como os irmãos são contados, o que :is(), :not(), :where() e :has() fazem com a validade e a especificidade, que pseudoclasses um documento estático nunca pode responder, e o que os navegadores fazem com um seletor que termina dentro de um colchete.
O que o head de uma página declara, e quem lê cada linhaWeb e HTTPSegurança e WAFO head de uma página HTML é escrito para máquinas, e cada linha é lida por uma máquina diferente sob regras diferentes: o navegador lê o title, a codificação e as diretivas pragma pelo HTML Standard; um rastreador de busca lê description, robots e canonical pela sua própria documentação publicada e pela RFC 6596; uma plataforma social lê Open Graph pelo ogp.me e twitter:* por um registro de 2023; um consumidor de dados estruturados lê JSON-LD pela Recomendação do W3C. O que cada parte exige, o que apenas prefere, o que é ignorado em silêncio, e o punhado de regras (um title, uma description, UTF-8 uma vez e cedo, exatamente um atributo identificador por meta) que são erros e não conselhos.