Honeypots já são utilizados por muitas pessoas para
forçar hackers a se denunciarem durante uma invasão. Servidores, ou mesmo redes
inteiras são usadas com este propósito. Um grande projeto, honeynet,
foi criado para registrar as ações de invasores em redes especialmente criadas
para isso, com grandes resultados.
Do ponto de vista corporativo, parece difícil implementar
redes e servidores exclusivas para serem invadidas. Os custos e até mesmo a
validade da idéia acabam fazendo com que outras medidas ganhem prioridade,
deixando os honeypots de lado. É possível, porém,
usarmos a idéia de uma isca de maneira diferente, mais simples de implementar. Ao invés de implementarmos
servidores como iscas, implementam-se informações como iscas. É o que
convencionei chamar de “honeytoken”.
Mas o que é um honeytoken? Qualquer informação que
possa ser plantada nos repositórios convencionais de informação, mas que não deveriam
ser detectadas na rede em situação normal, pode ser um
honeytoken. Uma conta de usuário, por exemplo, pode
ser um honeytoken extremamente eficaz. Ao manter-se
uma conta, aparentemente privilegiada e com uma senha fraca na base de
usuários, cria-se uma situação muito provável de ser explorada por invasor. Se
os sistemas de monitoramento e detecção de intrusos estiverem preparados, o uso
de tal conta pode ser imediatamente detectado, ajudando a identificar a
existência de alguém tentando usar uma conta “perdida” na rede em um acesso não
autorizado.
Muitas outras informações podem ser utilizadas como honeytokens.
Redes bem estruturadas, com políticas de acesso a dados bem implementadas,
são as mais beneficiadas desta técnica. Se o banco de dados, por exemplo, só
pode ser acessado por Stored Procedures
previamente definidas, podem ser inseridas nas tabelas linhas que agirão como honeytokens. Devidamente descartadas no retorno das procedures, tais linhas seriam prontamente detectadas no
caso de um acesso direto à tabela.
O sistema, porém, não é perfeito. Alguns detalhes acabam tornando o uso dos honeytokens um pouco menos efetivo. Entre eles, há o
problema da criptografia. O esquema dos honeytokens
depende muito de sistemas de inspeção de conteúdo, como um IDS de rede, por
exemplo. Já é notório o problema que a criptografia traz nestes casos. O honeytoken, ao estar encriptado,
não será detectado, e o comportamento suspeito passa despercebido. É claro que
outros mecanismos de detecção podem ser utilizados, porém é inegável que
estamos diminuindo o poder de detecção do sistema. Problema semelhante acontece
com a compactação de dados, que traz os mesmos problemas que a criptografia.
Sistemas de inspeção de conteúdo mais modernos, capazes de descompactar os dados
“on the fly”,
poderiam resolver o problema, porém a performance do
sistema seria seriamente comprometida.
Muitas pessoas já utilizam o conceito de honeytokens.
Recentemente um website especializado em anúncios de
emprego conseguiu provar que um de seus concorrentes estava contratando seus
serviços para roubar os currículos de seus clientes, através de currículos
forjados. Seriam currículos que não seriam mostrados em nenhum busca válida, a
não ser que alguém estivesse tentando acessar todos os currículos armazenados
no site. É o conceito dos honeytokens sendo implementado e mostrando resultados.
É muito importante, ao falar de honeypots ou honeytokens, lembrar que estas não são soluções únicas de
segurança. São ferramentas, que devem ser utilizadas como parte de uma
estratégia. A segurança em camadas, o “Security in Depth”, deve ser sempre usada como guia da implementação,
permitindo que cada ferramenta traga o seu benefício,
e que suas deficiências sejam compensadas pelas outras.