FISL9.0
Fórum Internacional de Software Livre
Port Knocking? Esqueça. Abrindo portas
remotamente no iptables com Single
Packet Authorization
Jansen Sena
Porto Alegre, RS – Brasil
Abril, 2008
Um pouco sobre o palestrante...
●Formação
–
Mestrado acadêmico pelo Instituto de Computação
da Unicamp (Campinas, SP)
–
LPI Certified Professional
●Atividades atuais
–
Atech Tecnologias Críticas
–
Revista PC&CIA
●Coluna Segurança Hightech
–
Consultor em TI (GNU/Linux, segurança e sw livre)
–
http://www.jsena.info/about
Contextualizando
●O mundo em rede...
–
Ambiente colaborativo e sem “malícias” é passado
–
Internet é hostil do ponto de vista de segurança
–
Segurança é um processo em constante evolução
●Firewall (filtragem) não é panacéia quanto a
implementação de um ambiente de rede seguro
–
Premissa básica #1: para ser invadido remotamente,
o primeiro passo é ter portas abertas
–
Premissa básica #2: nenhum software é perfeito e
isento de problemas
Premissa Básica #1
●
Target Enumeration
Premissa Básica #2
●Até tú, OpenSSH?
–
OpenSSH é considerado um bom exemplo de
software seguro, más....
●Vulnerabilidades recentes no OpenSSH
2008/04: OpenSSH X connections Session Hijacking
2008/03: OpenSSH X11 Cookie Local Authentication Bypass
2008/03: OpenSSH Duplicated Block Remote Denial of Service
2008/01: OpenSSHPortable GSSAPI Authentication Abort Information
2008/01: OpenSSH LINUX_AUDIT_RECORD_EVENT Remote Login Injection
2007/11: OpenSSH Privilege Separation Key Signature
Protegendo serviços...
●Serviços têm requisitos de proteção distintos
–
Serviços de acesso público
●HTTP, DNS, FTP...
●Onde a segurança deve ser implementada?
–Camada de aplicação, ambiente chrooted, atualização (patches)...
–
Serviços de acesso restrito (e.g. SSH???)
●Acessados, esporadicamente, por um grupo reduzido
●TCP Wrappers??? AllowUsers (sshd_config)???
–Medidas são importantes, mas não impedem acesso ao serviço
que fica exposto a investidas de atacantes...
●Restrição de acesso por IP (filtragem)
–Esse NÃO é o cenário adequado na maioria dos casos
O que é o Port Knocking?
●Criado inicialmente em 2003
●http://www.portknocking.org
–
Mais de 30 projetos listados
●Em poucas palavras...
–
Acesso a um serviço restrito é liberado após receber
uma sequëncia prédeterminada de pacotes
–
Knock sequence: sequência ordenada de pacotes
contendo números de portas (UDP/TCP)
previamente estabelecidos entre cliente e “servidor”
–
Acesso é retringido novamente após timeout
O que é o Port Knocking?
Port 4937 (TCP Syn)
Port 9781 (TCP Syn)
Port 1298 (TCP Syn)
Port 7198 (TCP Syn)
Kn
oc
k
se
qu
en
ce
Port Knocking
Daemon
Port Knocking
Client
Ip
ta
bl
es
ru
le
s
lib
pc
ap
Port 22/SSH (TCP Syn)
SSH Client
SS
H
D
ae
m
on
SSH Client
Port 22/SSH (TCP Syn)
SSH Client
Port 22/SSH (TCP Syn/Ack)
Client
Pode ser
Server
Limitações do Port Knocking...
Knock sequence
SSH access
Knock sequence
sniffer
SSH access!!!
Knock sequence
REPLAY
Sysadmin
Atacante
Servidor
Limitações do Port Knocking...
Knock sequence
Sysadmin
Atacante
Servidor
Acesso não será
liberado ao
sysadmin
Limitações do Port Knocking...
●Outras limitações...
–
Criptografia restrita pelo fato de somente o espaço
das portas TCP/UDP (2 bytes) serem utilizados
–
Pacotes podem ser entregues fora de ordem
●Quebra da knock sequence
●Cliente pode aumentar o intervalo de envio
–Medida não resolve o problema completamente
–Outros problemas podem surgir com o aumento exagerado
–
“Outros” possuem mesmo nível de acesso quando
estão na mesma rede protegida por NAT
●Nesse caso, não é necessário replay
...e o Single Packet Authorization (SPA)?
●Herda os benefícios do Port Knocking e...
–
...resolve muitas das suas limitações!
●Estrutura do SPA
–
Muito similar à do Port Knocking
●Possui componentes cliente e servidor
●Servidor possui uma política de filtragem em DROP
●Servidor monitora pacotes de maneira “passiva”
–Entrada no syslog gerado pelo “LOG” do iptables ou libpcap
–
Principal diferença: informações são
encaminhadas na parte de dados do pacote!!!
Mais sobre o Single Packet Authorization...
●Replay não é uma limitação
–
Cada pacote possui em seu conteúdo (cifrado) um
número aleatório...
●Ao ser decifrado, número é mantido em cache no servidor
●Reenvio de pacote por atacante não subverte o SPA
●Diferentes níveis de acesso
–
Nome do usuário, incluso no pacote também é
utilizado para prover diferentes níveis de acesso
●Flexibilidade e versatilidade
Mais sobre o Single Packet Authorization...
●Spoof de pacotes por parte de um atacante não
inviabiliza o processo de autenticação
–
Utiliza somente um pacote ao invés de vários
●Não é registrado por IDS intermediários como
um port scan
–
Port knocking possui essa fragilidade
Single Packet Authorization na prática
●Obtendo o códigofonte do fwknop
–
http://www.cipherdyne.org/fwknop
–
Existem pacotes RPM (précompilados)
●Instalando dependências...
–
Cenário considerado: Ubuntu Linux 7.10
# apt-get install build-essential libpcap-dev
●
Compilando...
# tar -xjvf fwknop-1.9.3-1.tar.bz2
# cd fwknop-1.9.3-1
Single Packet Authorization na prática
●Nosso ambiente “didático”
Gandalf
Aragorn
SSH access
Iptables rules
“Servidor” é passivo e não se parece com os tradicionais onde
existem BSD sockets em estado de listening.
Single Packet Authorization na prática
●Primeira alternativa: criptografia simétrica
–
Configuração básica do servidor
/etc/fwknop/access.conf:
SOURCE: ANY;
OPEN_PORTS: tcp/22;
FW_ACCESS_TIMEOUT: 30;
KEY: jsena123;
# /etc/init.d/fwknop start
Segredo compartilhado único!
Single Packet Authorization na prática
Single Packet Authorization na prática
●
Finalmente...
1
2
Single Packet Authorization na prática
Single Packet Authorization na prática
●Considerações da criptografia simétrica
–
Implementação mais simples e rápida
–
Necessita do compartilhamento de um segredo
único entre os vários usuários
–
Deve ser utilizada, preferencialmente, apenas em
ambientes de testes ou em locais com requisitos de
segurança menos restritivos
Single Packet Authorization na prática
●Segunda alternativa: criptografia assimétrica
–
Primeiros passos...
●Criar par de chaves para cliente e servidor
●Exportar a chave criada e copiar para cliente/servidor
$ gpg –genkey
$ gpg a export <KEYID> pubkey.txt
$ scp pubkey.txt
usuario@host
:~
●Importar a chave
●Assinar a chave importada
$ gpg --import pubkey.txt
Single Packet Authorization na prática
●
Segunda alternativa: criptografia assimétrica
Single Packet Authorization na prática
●Segunda alternativa: criptografia assimétrica
/etc/fwknop/access.conf:
SOURCE: ANY;
OPEN_PORTS: tcp/22;
FW_ACCESS_TIMEOUT: 30;
GPG_HOME_DIR: /home/jansen/.gnupg;
GPG_DECRYPT_ID: 0D1ED5DB;
GPG_DECRYPT_PW: 123;
GPG_REMOTE_ID: 416C76F1;
# /etc/init.d/fwknop restart
Single Packet Authorization na prática
●
Segunda alternativa: criptografia assimétrica
Single Packet Authorization na prática
●
Segunda alternativa: criptografia assimétrica
SPA é segurança por obscuridade?
●Implementações de port knocking e SPA são
software livre e,portanto, estão disponíveis para
estudo, avaliação e crítica
●Não mostrar passwords e chaves criptográficas
representa segurança por obscuridade?
–
O mesmo aplicase ao SPA
●Segurança POR obscuridade é diferente de
segurança com obscuridade
Mil maravilhas?
●Solução pode aumentar a “falsa sensação de
segurança” de muitos sysadmins
–
Bugs (e.g. libpcaps) e outros potenciais problemas
●Necessidade de gerenciamento adicional de
passwords e chaves criptográficas
–
Problema mais crítico quando se utiliza criptografia
de chave assimétrica
●Pacotes de autorização são transmistidos sem
qualquer mecanismo de “confiabilidade”
Links interessantes
●
http://www.cipherdyne.org/fwknop
●
