mrash/fwknopAutorizaçã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:
tcpdump -w <file>), do escritor pcap ULOG do iptables, ou
diretamente via um socket UDP no modo --udp-server.O projeto fwknop é lançado como software de código aberto sob os termos da GNU General Public License (GPL v2) ou (a seu critério) qualquer versão posterior. A versão mais recente pode ser encontrada em http://www.cipherdyne.org/fwknop/
Este arquivo README descreve o estado atual do projeto fwknop a partir do
lançamento 2.5 em julho de 2013. Atualmente, temos uma implementação da
biblioteca Firewall Knock Operator; libfko, bem como o cliente fwknop e
aplicações servidoras. A biblioteca fornece a API e a funcionalidade de back-end
para gerenciar os dados de Autorização por Pacote Único (SPA) que os outros componentes
do fwknop empregam. Também pode ser usada por outros programas que precisam de
funcionalidade SPA (veja o diretório perl para o módulo FKO perl como exemplo,
e há bindings python também no diretório python).
Se você está atualizando de uma versão antiga do fwknop (e isso inclui a implementação original em perl também), então você vai querer ler o link a seguir para garantir uma transição suave para o fwknop-2.5 ou posterior:
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#backwards-compatibility
Esta distribuição usa GNU autoconf para configurar a compilação. Por favor, consulte
o arquivo INSTALL para noções básicas sobre o uso do autoconf.
Existem algumas opções "configure" específicas do fwknop. Elas são (extraídas de ./configure --help):
--disable-client Não compilar o componente cliente do fwknop. O
padrão é compilar o cliente.
--disable-server Não compilar o componente servidor do fwknop. O
padrão é compilar o servidor.
--with-gpgme suporte para criptografia gpg usando libgpgme
[default=check]
--with-gpgme-prefix=PFX prefixo onde o GPGME está instalado (opcional)
--with-gpg=/path/to/gpg Especificar o caminho para o executável gpg que gpgme irá
usar [default=check path]
--with-firewalld=/path/to/firewalld
Especificar o caminho para o executável firewalld
[default=check path]
--with-iptables=/path/to/iptables
Especificar o caminho para o executável iptables
[default=check path]
--with-ipfw=/path/to/ipfw
Especificar o caminho para o executável ipfw [default=check
path]
--with-pf=/path/to/pfctl
Especificar o caminho para o executável pf [default=check
path]
--with-ipf=/path/to/ipf Especificar o caminho para o executável ipf [default=check
path]
Exemplos:
./configure --disable-client --with-firewalld=/bin/firewall-cmd
./configure --disable-client --with-iptables=/sbin/iptables --with-firewalld=no
Para aqueles que estão atualmente usando a versão Perl e planejam migrar para esta versão, há algumas coisas a serem consideradas:
Nem todos os recursos e funcionalidades do fwknop baseado em Perl foram portados para esta implementação. Consideramos importante manter a versão C tão enxuta e leve quanto possível. A maioria das características/funções omitidas (como alertas por e-mail) podem ser realizadas por outros meios (ou seja, usar um script externo para monitorar arquivos de log e alertar com base em mensagens de log apropriadas).
Existem algumas diferenças nas diretivas e valores dos arquivos de configuração e acesso do fwknop. Algumas delas são bastante sutis. Você deve prestar atenção cuidadosa à documentação e aos comentários nesses arquivos.
Se você está obtendo esta distribuição do git, deve executar o
script autogen.sh para gerar os arquivos autoconf. Se você receber erros sobre
diretórios ou arquivos ausentes, tente executar autogen.sh novamente. Depois disso,
você pode executar autoreconf -i quando quiser regenerar a configuração.
Se, por algum motivo, o autoreconf não funcionar para você, o script autogen.sh
deve ser suficiente.
As fontes nroff das páginas de manual do fwknop e fwknopd estão incluídas em seus respectivos diretórios (cliente e servidor). Esses arquivos nroff são derivados das fontes asciidoc no diretório 'docs'. Consulte o README em docs para obter detalhes.