
Autorização de Pacote Único > Port Knocking
O fwknop implementa um esquema de autorização conhecido como Autorização por Pacote Único (SPA) para forte ocultação de serviços. O SPA requer apenas um único pacote que é criptografado, não reproduzível e autenticado via HMAC para comunicar o acesso desejado a um serviço que está oculto atrás de um firewall em uma postura de filtragem de rejeição padrão. A principal aplicação do SPA é usar um firewall para descartar todas as tentativas de conectar a serviços como SSH, a fim de tornar a exploração de vulnerabilidades (tanto 0-day quanto código não corrigido) mais difícil. Como não há portas abertas, qualquer serviço ocultado pelo SPA naturalmente não pode ser escaneado com o Nmap. O projeto fwknop suporta quatro firewalls diferentes: iptables, firewalld, PF e ipfw em Linux, OpenBSD, FreeBSD e Mac OS X. Há também suporte para scripts personalizados para que o fwknop possa ser adaptado para suportar outras infraestruturas como ipset ou nftables.
O SPA é essencialmente a próxima geração do Port Knocking (PK), mas resolve muitas das limitações apresentadas pelo PK, mantendo seus benefícios principais. As limitações do PK incluem uma dificuldade geral em proteger contra ataques de repetição, cifras assimétricas e esquemas HMAC geralmente não são suportáveis de forma confiável, e é trivialmente fácil montar um ataque DoS contra um servidor PK apenas falsificando um pacote adicional em uma sequência PK enquanto ela atravessa a rede (convencendo assim o servidor PK de que o cliente não conhece a sequência correta). Todas essas deficiências são resolvidas pelo SPA. Ao mesmo tempo, o SPA oculta serviços atrás de uma política de firewall de rejeição padrão, adquire dados SPA de forma passiva (geralmente via libpcap ou outros meios) e implementa operações criptográficas padrão para autenticação e criptografia/descriptografia de pacotes SPA.
Os pacotes SPA gerados pelo fwknop utilizam HMAC para criptografia autenticada no modelo de
criptografar-depois-autenticar. Embora o uso de um HMAC seja atualmente opcional (habilitado
via a opção de linha de comando --use-hmac), é altamente recomendado por três razões:
A última razão acima é por que um HMAC ainda deve ser usado mesmo quando os pacotes SPA são
criptografados com GnuPG, devido ao fato de que os dados SPA não são enviados através das
funções libgpgme a menos que o HMAC seja verificado primeiro. GnuPG e libgpgme são corpos de
código relativamente complexos, e portanto limitar a capacidade de um potencial atacante de
interagir com esse código através de uma operação HMAC ajuda a manter uma postura de segurança
mais forte. Gerar um HMAC para comunicações SPA requer uma chave dedicada além da chave de
criptografia normal, e ambas podem ser geradas com a opção --key-gen.
O fwknop criptografa pacotes SPA com a cifra de bloco Rijndael ou via GnuPG e cifra assimétrica
associada. Se o método de criptografia simétrica for escolhido, então como de costume a chave
de criptografia é compartilhada entre o cliente e o servidor (veja o arquivo
/etc/fwknop/access.conf para detalhes). A chave de criptografia real usada para a
criptografia Rijndael é gerada através do algoritmo padrão de derivação de chave PBKDF1,
e o modo CBC é definido. Se o método GnuPG for escolhido, então as chaves de criptografia
são derivadas dos key rings GnuPG.
Pessoas que usam Autorização por Pacote Único (SPA) ou seu primo de segurança questionável, Port Knocking (PK), normalmente acessam o SSHD executando no mesmo sistema onde o software SPA/PK está implantado. Isto é, um firewall executando em um host tem uma política de rejeição padrão contra todas as conexões SSH de entrada para que o SSHD não possa ser escaneado, mas um daemon SPA reconfigura o firewall para conceder temporariamente acesso a um cliente SPA autenticado passivamente:
"Uso básico do SPA para acessar o SSHD"
O fwknop suporta o acima, mas também vai muito além e faz uso robusto de NAT (para firewalls iptables/firewalld). Afinal, firewalls importantes são geralmente gateways entre redes, ao contrário de serem apenas implantados em hosts autônomos. O NAT é comumente usado nesses firewalls (pelo menos para comunicações IPv4) para fornecer acesso à Internet a redes internas que estão no espaço de endereço RFC 1918, e também para permitir que hosts externos acessem serviços hospedados em sistemas internos.
Como o fwknop se integra com NAT, o SPA pode ser aproveitado para acessar serviços internos através do firewall por usuários na Internet externa. Embora isso tenha muitas aplicações em redes tradicionais modernas, também permite que o fwknop suporte ambientes de computação em nuvem como o Amazon AWS:
"Uso do SPA em ambientes de nuvem Amazon AWS"
A interface de usuário oficial multiplataforma do cliente fwknop, fwknop-gui
(download, github),
é desenvolvida por Jonathan Bennett. A maioria dos modos SPA do lado do cliente são suportados,
incluindo solicitações NAT, chaves HMAC e Rijndael (GnuPG ainda não é suportado), salvamento
de estrofe fwknoprc e muito mais. Atualmente o fwknop-gui é executado em Linux, Mac OS X e
Windows - aqui está uma captura de tela do OS X:
"fwknop-gui no Mac OS X"
Da mesma forma, um cliente Android atualizado
também está disponível.
Um tutorial abrangente sobre o fwknop pode ser encontrado aqui:
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html
A seguir está uma lista completa de recursos suportados pelo projeto fwknop: