Regras de entrada de SSH e VPN: o que a lista de permissões realmente controla

Siga uma ligação do cliente ao anfitrião: que gancho atravessa, porque um bloqueio e uma recusa significam regras diferentes e porque rejeitar nunca é uma política.

Ligue-se uma vez antes de alterar uma regra e registe se o cliente fica pendurado ou é recusado de imediato. Essa única diferença diz-lhe que decisão descartou o pacote e poupa uma hora de leitura de ficheiros de política. O resto do percurso é curto: o pacote atravessa um gancho, corresponde a uma regra e chega a um ouvinte ou não. Uma lista de permissões é apenas contabilidade em torno desses três factos.

Siga uma tentativa de SSH até ao gancho de entrada

Um cliente envia um SYN para o endereço do anfitrião na porta 22, e o núcleo decide se esse pacote é para um serviço local. Se for, o caminho de entrada corre e o conjunto de regras aceita o pacote ou descarta-o. O silêncio significa que o SYN morreu antes de o ouvinte o ver, enquanto uma recusa rápida significa que algo respondeu com um reset. São veredictos diferentes de regras diferentes, e ambos são resultados legítimos.

Confirme depois o ouvinte, porque nenhuma regra salva um serviço que não existe. Execute ss -ltnp e verifique se algo está ligado à porta e à família de endereços que espera, e depois leia ssh -v no cliente para ver onde para.

O encaminhamento é uma decisão à parte

Num servidor VPN o gancho mais interessante é forward, porque o tráfego do cliente é encaminhado através da máquina em vez de lhe ser entregue. Um anfitrião que só executa o seu próprio cliente VPN precisa de um conjunto de regras muito menor do que um que reencaminha pacotes de outras pessoas. Misturar os dois desenhos numa só máquina produz regras que parecem corretas e não deixam passar nada.

Escreva a política interior como uma pergunta própria: que endereços de cliente podem alcançar que destinos através do túnel. Mantenha o caminho administrativo, como o SSH, no caminho de entrada com a sua própria restrição de origem. Uma regra forward permissiva acrescentada durante os testes é o defeito clássico que sobrevive ao teste, por isso reveja todo o conjunto de regras após uma alteração em vez da linha que editou. Abrir o ouvinte do túnel não é permissão para cada cliente ligado administrar o anfitrião.

Descartar e rejeitar são ações, não políticas

A política de uma cadeia base aceita ou descarta, e essa é toda a lista de opções, como diz a referência do nftables. A rejeição existe como ação de regra com uma resposta escolhida, e por isso escrevê-la como política falha tanto no nftables como no iptables. Na prática, um drop não dá ao cliente qualquer informação, enquanto um reject lhe dá um erro sobre o qual pode agir.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Leia esse esboço como a forma de uma decisão e não como um ficheiro para colar, porque os intervalos de endereços são exemplos. Um reject explícito na porta SSH faz um cliente não autorizado falhar num segundo em vez de esperar por um tempo limite, o que encurta a sua própria depuração. O silêncio dissuade a análise casual e não diz absolutamente nada a um utilizador autorizado. Escolha por serviço e anote porquê, caso contrário a pessoa seguinte muda tudo de volta.

Mantenha o tráfego de controlo de que realmente precisa

Bloquear todo o ICMP é um valor predefinido popular que quebra a descoberta de MTU do caminho, e o sintoma é uma ligação que se estabelece e depois encrava em pacotes maiores. A descoberta de vizinhos em IPv6 depende dos seus próprios tipos de ICMPv6, e descartá-los quebra a ligação antes de qualquer regra TCP ser consultada. Ambos pertencem à lista de permissões como dependências nomeadas e não como permissões gerais. Uma política que quebra a descoberta em silêncio é pior do que uma que admite um pouco de tráfego de diagnóstico.

Permita os estados established e related para as ligações que iniciou, e deixe o motor com estado tratar das respostas. Depois confirme que o caminho de resposta não está bloqueado mais para fora, porque uma restrição apenas de saída a montante produz o mesmo tempo limite que estava prestes a atribuir ao anfitrião.

Prove a recuperação antes de retirar o caminho antigo

Mantenha uma sessão de consola aberta, aplique a alteração e abra uma ligação de gestão completamente nova a partir de outro terminal. Uma sessão existente não prova nada, porque pode sobreviver a uma regra que bloqueia cada novo início de sessão, o que a torna o falso positivo mais convincente do trabalho com firewalls. Se um sistema de monitorização verifica o anfitrião, acrescente o seu endereço de origem antes da alteração e não depois do primeiro alerta. Depois teste um pacote grande e um pequeno para provar que a descoberta ainda funciona.

Para um serviço VPN, repita a partir de um cliente que nunca se ligou, porque uma sessão retomada pode reutilizar estado que uma nova tem de negociar. Registe o conjunto exato de regras que passou, com uma soma de verificação ou uma cópia, para que uma edição posterior possa ser comparada em vez de adivinhada. Coordene com quem detém a ordem das regras, porque uma regra anterior ganha em silêncio à que acrescentou.

Artigos relacionados